












































我 上 大 学 时 ， 就 开始 在 CSDN 上 写 技术 博客 ， 目 的 在 于 记录 平时 遇 到 的 一 些 问题 以 及 研究 的 技术 细节 ， 好 在 将 来 可 以 进行 查阅 。 随 着 时 间 的 增长 ， 我 开始 专注 于 某 个 技术 模块 ， 因 为 这 样 可 以 让 我 对 
体 某 项 技术 有 更 深入 的 研究 ， 写 出 的 内 容 也 会 更 加 系统 化 ， 而 HDFS 就 是 其 中 一 个 我 持续 研究 的 技术 模块 。 同 时 作为 一 名 Hadoop 社 区 的 活跃 贡献 者 ， 我 也 会 将 社区 上 一 些 比较 有 意思 的 东西 分 享 到 博客 上 ， 
许多 博 友 给 了 不 少 反 馈 ， 描 述 他 们 在 工作 中 碰 到 的 一 些 实际 问题 。 在 这 样 不 断 的 写作 、 交 流 过 程 中 ， 我 得 到 了 快速 成 长 。 目 前 大 数据 领域 相关 的 书籍 并 不 是 很 多 ， 而 专门 讲解 其 中 一 个 模块 的 书 则 更 少 ， 所 
以 我 将 我 过 去 一 年 多 时 间 内 关于 HDFS 的 博客 文章 进行 了 整理 、 改 进 ， 同 时 也 加 入 了 一 些 新 的 内 容 。 可 以 这 么 说 ， 本 书 的 内 容 源 自 博客 ， 但 是 超越 博客 。 










































































本 书 不 会 是 纯 源码 分 析 的 书籍 。 首 先 ， 我 把 工作 实践 中 遇 到 的 许多 经 验 写 入 了 书 中 ， 第 7 章 便 属于 纯 实践 型 的 经 验 总 结 。 其 次 ， 本 书 会 是 一 个 比较 “新 ”的 书 ， 这 里 的 “新 ”并 不 是 指 所 分 析 的 代码 版 本 
新 ， 而 是 包含 了 HDFS 未 来 的 一 些 比 较 棒 的 功能 特性 ， 以 及 Hadoop 社 区 目前 在 做 的 一 些 事情 。 在 这 本 书 中 ， 你 会 看 到 许多 与 社区 相关 的 JIRA， 了 解 如 何 从 社区 上 找到 问题 的 解决 办 法 。 期 待 本 书 能 给 你 带 来 
更 多 的 启发 。 









































本 书 适合 具有 一 定 Java 语 言 基础 的 同学 ， 尤 其 适合 以 下 读者 朋友 : 








“ 大 数据 架构 师 、 开 发 者 、 运 维 工程 师 。 


“ 高 年 级 本 科 生 或 研究 生 。 


“ 热衷 于 分 布 式 存储 技术 的 爱好 者 。 








本 书 分 为 三 大 部 分 ，“ 核 心 设计 篇 ”介绍 HDFS 的 基本 原理 、 数 据 管理 与 策略 等 ，“ 细 节 实 现 篇 ”介绍 HDFS 的 块 处 理 、 流 量 处 理 、 结 构 分 析 等 ，“ 解 决 方案 篇 ”介绍 数据 管理 技术 与 方案 、 数 据 读 写 技 
术 、 异 常 处 理 等 。 


第 一 部 分 “核心 设计 篇 ”包括 内 容 如 下 : 





第 1 章 介绍 HDFS 现 有 的 数据 存储 方式 ， 主 要 介绍 其 中 的 内 存 存 储 和 异 构 存储 两 个 方面 。 


第 2 章 介绍 HDFS 目 前 内 部 几 种 主要 的 功能 机 制 ， 包 括 缓存 管理 、 快 照管 理 等 。 

















第 3 章 介绍 HDFS 比 较 新 颖 的 一 些 功 能 ， 以 及 目前 较 少 被 人 用 到 的 功能 特性 。 





第 二 部 分 “细节 实现 篇 ”包括 内 容 如 下 : 


第 4 章 介 绍 HDFS 的 块 处 理 相关 操作 ， 主 要 处 理 场景 包括 块 如 何 组 织 、 上 报 处 理 的 过 程 以 及 多 余 块 的 清除 。 
































第 5 章 介绍 HDFS 的 流量 处 理 过 程 ， 包 括 HDFS 目 前 流量 处 理 的 场景 以 及 Balancer 工 具 的 数据 平衡 原理 和 优化 。 





















































第 6 章 介绍 HDFS 一 些 特殊 的 结构 对 象 类 ， 包 括 这 些 类 的 作用 、 原 理 以 及 运用 场景 。 
三 部 分 “解决 方案 篇 。 包 括 内 容 如 下 : 
第 7 章 介绍 与 HDFS 相 关 的 多 套 运 维 管理 的 操作 方案 ， 包 括 数据 迁移 、 数 据 监控 等 方面 。 


第 8 章 介绍 HDFS 写 磁盘 时 的 一 些 优化 策略 和 改造 方案 。 








第 9 章 介绍 HDFS 的 一 些 异 常 场景 ， 并 给 出 了 相应 的 解决 方案 。 


由 于 笔者 水 平 有 限 ， 本 书 难免 会 有 出 错 或 者 介绍 不 明确 的 地 方 ， 妃 请 读者 批评 指正 ， 可 以 发 送 关 于 本 书 的 意见 和 建议 到 我 的 个 人 邮箱 : yqtin@apache.org。 本 书 所 涉及 的 源码 ， 大 家 可 以 从 Hadoop 的 
Git 地 址 上 进行 下 载 : https://github.com/apache/hadoop， 其 中 ， 不 同 的 分 支 对 应 不 同 版 本 的 代码 。 相 关 Git 地 址 和 CSDN 博 客 地 址 如 下 : 


"Git 地 址 : https://github.com/linyiqun 


CSDN 地 址 : http://blogcsdn.net/androidlushangderen 





感谢 机 械 工业 出 版 社 的 吴 怡 编辑 ， 在 我 写作 的 过 程 中 ， 不 断 指 出 其 中 的 不 足 之 处 ， 督 促 和 引导 我 完成 本 书 的 编写 。 











感谢 蘑菇 街 数据 平台 部 的 同事 们 ， 在 工作 中 不 断 地 给 予 我 帮助 和 支持 ， 协 助 我 解决 各 种 各 样 的 问题 ， 于 是 才 有 了 本 书 中 所 展现 的 精彩 内 容 。 
林 意 群 


2017 年 2 月 


第 一 部 分 “核心 设计 篇 


第 1 章 ”HDFS 的 数据 存储 








本 章 将 从 HDFS 的 数据 存储 开始 说 起 ， 因 为 正 是 先 有 了 数据 的 存储 ， 才 有 后 续 的 写 入 和 管理 等 操作 。HDFS 的 数据 存储 包括 两 块 : 一 块 是 HDFS 内 存 存储 ， 另 一 块 是 HDFS 异 构 存 储 。HDFS 内 存 存储 是 一 
种 十 分 特殊 的 存储 方式 ， 将 会 对 集群 数据 的 读 写 带 来 不 小 的 性 能 提升 ， 而 HDFS 异 构 存储 则 能 帮助 我 们 更 加 合理 地 把 数据 存 到 应 该 存 的 地 方 。 
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第 1 章 ”HDFS 的 数据 存储 











本 章 将 从 HDFS 的 数据 存储 开始 说 起 ， 因 为 正 是 先 有 了 数据 的 存储 ， 才 有 后 续 的 写 入 和 管理 等 操作 。HDFS 的 数据 存储 包括 两 块 : 一 块 是 HDFS 内 存 存 储 ， 另 一 块 是 HDFS 异 构 存储 。HDFS 内 存 存储 是 一 
种 十 分 特殊 的 存储 方式 ， 将 会 对 集群 数据 的 读 写 带 来 不 小 的 性 能 提升 ， 而 HDFS 异 构 存储 则 能 帮助 我 们 更 加 合理 地 把 数据 存 到 应 该 存 的 地 方 。 





1.1 HDFS 内 存 存 储 








HDFS 的 内 存 存储 是 HDFS 所 有 数据 存储 方式 中 比较 特殊 的 一 种 ， 与 之 后 将 会 提 到 的 HDFS 缓 存 有 一 些 相 同 之 处 : 都 用 机 器 的 内 存 作为 存储 数据 的 载体 。 不 同 之 处 在 于 : HDFS 缓 存 需要 用 户主 动 设置 目标 
待 缓存 的 文件 、 目 录 ， 其 间 需 要 使 用 HDFS 缓 存 管理 命令 。 而 HDFS 内 存 存储 策略 : LAZY_PERSIST 则 直接 将 内 存 作为 数据 存放 的 载体 ， 可 以 这 么 理解 ， 此 时 节点 的 内 存 也 充当 了 一 块 “ 磁 盘 ”。 只 要 将 文件 
设置 为 内 存 存储 方式 ， 最 终 会 将 其 存储 在 节点 的 内 存 中 。 综 合 地 看 ，HDFS 缓 存 更 像 是 改进 用 户 使 用 的 一 种 功能 ， 而 HDFS 内 存 存 储 则 是 从 底层 扩展 了 HDFS 的 数据 存储 方式 。 本 节 将 对 HDFS 内 存 存 储 策略 进 
行 更 细致 的 分 析 。 

































































1.1.1 HDFS 内 存 存储 原理 
对 于 内 存 存 储 的 存储 策略 ， 可 能 很 多 人 会 存 有 这 么 几 种 看 法 : 
' 数据 临时 维持 在 内 存 中 ， 服 务 一 停止 ， 数据 全 部 丢失 。 


“ 数据 存在 于 内 存 中 ， 在 服务 停止 时 做 持久 化 处 理 ， 最 终 将 数据 全 部 写 入 到 磁盘 。 





仔细 来 看 以 上 这 2 种 观点 ， 其 实 都 有 不 小 的 瑕 病 : 


“ 第 一 个 观点 ， 服 务 一 旦 停止 ， 内 存 数据 全 部 丢失 ， 这 是 无 法 接受 的 ， 我 人 
一 部 分 数据 ， 内 存 空 间 迟 早 会 被 耗 尽 。 


> 


能 容忍 内 存 中 少量 的 数据 丢失 。 这 个 观点 的 另 一 个 问题 是 ， 内 存 的 存储 空间 是 有 限 的 ， 在 服务 运行 过 程 中 如 果 不 及 时 处 理 


“ 第 二 个 观点 ， 在 服务 停止 退出 的 时 候 做 持久 化 操作 ， 同 样 会 面临 上 面 提 到 的 内 存 空间 的 限制 问题 。 如 果 机 器 的 内 存 足 够 大 ， 数 据 可 能 会 很 多 ， 那 么 最 后 写 入 磁盘 的 阶段 速度 会 很 慢 。 





























所 以 一 般 情况 下 ， 通 用 的 、 比 较 好 的 做 法 是 异步 持久 化 ， 什 么 意思 呢 ? 在 内 存 存储 新 数据 的 同时 ， 持 久 化 距离 当前 时 刻 最 远 (存储 时 间 最 早 ) 的 数据 。 换 一 个 通俗 的 解释 ， 好 比 有 个 内 存 数据 块 队列 ， 
在 队列 头 部 不 断 有 新 增 的 数据 块 插入 ， 就 是 待 存储 的 块 ， 因 为 资源 有 限 ， 需 要 把 队列 尾部 的 块 ， 也 就 是 更 早 些 时 间 点 的 块 持久 化 到 磁盘 中 ， 这 样 才 有 空间 存储 新 的 块 。 然 后 形成 这 样 的 一 个 循环 ， 新 的 块 加 
入 ， 老 的 块 移 除 ， 保 证 了 整体 数据 的 更 新 。 














HDFS 的 LAZY_PERSIST 内 存 存储 策略 用 的 就 是 这 套 方法 ， 原 理 如 
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1 ) 用 LAZY PERSIST 策略 创建 文 
件 并 请 求 数 据 块 


2 ) 返回 本 地 DN 





NameNode 
RAM 侯 盘 了 驱 动 从 
4 所 本 音量 是 副 避 6 ) 检查 并 异步 
数据 一 “ 国 硬 硬是 硬 硬 地 将 数据 
写 到 磁盘 





DataNode 进程 





图 1-1 LAZY_PERSIST 策 略 原理 图 





























上 面 描述 的 原理 在 图 中 的 表示 是 第 4 个 步骤 和 第 6 个 步骤 。 第 4 步 写 数据 到 内 存 中 ， 第 6 步 异 步 地 将 数据 写 到 磁盘 。 前 面 几 个 步骤 是 如 何 设置 StorageType 的 操作 ， 在 下 文中 会 具体 提 到 。 所 以 异步 存储 的 








大 体 步骤 可 以 归纳 如 下 : 


1) 对 目标 文件 目录 设置 StoragePolicy 为 LAZY_PERSIST 的 内 存 存储 策略 。 





2) 客户 端 进 程 向 NameNode 发 起 创建 / 写 文件 的 请 求 。 





居 块 写 入 RAM 内 存 中 ， 同 时 启动 异步 线程 有 





3) 客户 端 请 求 到 具体 的 DataNode 后 DataNode 会 把 这 些 数 提 








内 存 的 异步 持久 化 存储 是 内 存 存 储 与 其 他 介质 存储 不 同 的 地 方 。 这 也 是 LAZY_PERSIST 名 称 的 源 由 ， 数 


1.1.2 ”Linux 虚 拟 内 存盘 





民 务 将 内 存 数 据 持久 化 写 到 磁盘 上 。 


居 不 是 马上 沙盘 ， 而 是 懒惰 的 、 延 时 地 进行 处 理 。 














忆 

















识 点 : 


AFA 


这 里 需要 了 解 一 个 额外 的 知 
实在 Linux 中 ， 的 确 有 将 内 存 模拟 为 一 个 块 盘 的 技术 ， 叫 虚拟 内 存盘 (RAM disk) 。 这 是 一 种 模拟 的 盘 ， 实 | 
如 tmpfs、ramfs。 关 于 tmpfs 的 
































1.1.3 ”HDFS 的 内 存 存 储 流程 分 析 








下 面 讲述 本 章 的 核心 内 容 : HDFS 内 存 存储 的 主要 流程 。 不 要 小 看 这 个 存储 策略 ,里 
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1.HDFS 文 件 内 存 存储 策略 设置 











要 想 让 文件 数据 存储 到 内 存 中 ， 一 开始 要 做 的 操作 是 设置 此 文件 的 存储 策略 ， 即 上 面 提 到 的 LAZY_PERSsIST， 而 不 是 使 
的 。 设 置 存储 策略 的 方法 目前 有 以 下 3 种 : 
第 一 种 方法 ， 通 过 命令 行 的 方式 ， 调 用 如 下 命令 : 














Linux 虚 拟 内 存盘 。 之 前 笔者 也 一 直 有 个 疑惑 ， 内 存 也 可 以 当 作 一 个 块 盘 使 有 


体内 容 ， 大 家 可 以 查阅 维基 百科 等 资料 。 通 过 此 项 技术 ， 我 们 就 可 以 将 机 器 内 存 利 上 


的 过 程 可 并 不 简单 ， 在 下 


是 在 学 习 此 模块 知识 之 前 ， 特 意 查 了 相关 的 资料 。 其 
内 存 式 存储 文件 系统 下 结合 使 用 ， 比 
了 。 


的 吗 ? 了 
内 存盘 可 以 在 某 些 特定 的 
虚拟 盘 供 DataNode 使 有 


内 存 不 就 是 临时 存 数据 有 
际 数据 都 是 存放 在 内 存 中 的 。 虚 拟 
起 来 ， 作 为 一 块 独立 的 







































































图 





的 内 容 中 ， 笔 者 会 给 出 比较 多 的 过 程 








， 帮 助 大 家 理解 。 


H 




















默认 的 存储 策略 : StoragePolicy.DEFAULT， 默 认 策略 的 存储 介质 是 DISK 类 型 











hdfs storagepolicies -setStoragePolicy -path <path> -Policy LAZY PERSIST 





这 种 方式 比较 方便 、 快 速 。 




















对 应 的 程序 方法 ， 比 如 调用 暴露 在 外 部 的 create 文 件 方法 ， 但 是 得 带 上 参数 CreateFl 





第 二 种 方法 ， 调 








FSDataOutputStream fos = 
fs .create( 
path, 
FsPermission.getFileDefault (), 
EnumSet .of (CreateFlag .CREATE, CreateFlag.LAZY PERSIST), 
bufferLength, 
replicationFactor, 
blockSize, 
null); 


ag.LAZY_PERSIST。 如 下 所 示 : 














上 述 方 式 最 终 调用 的 是 DFSClient 的 create 同 名 方法 ， 如 下 所 示 : 


//_DFSC1ient 创 建文 件 方法 
public DFSOutputStream create (String src, FsPermission permission, 
EnumSet<CreateFlag> flag, short replication, long blockSize, 
Progressable progress, int buffersize, ChecksumOpt checksumOpt) 
throws IOException { 
return createl(src, permission, flag, true, 
replication, blockSize, progress, buffersize, checksumOpt, null); 





























方法 经 过 RPC 层 层 调 








， 经 过 FSNamesystem， 最 终 会 到 FSDirWriteFileOp 的 startFile 方 法 ， 在 此 方法 内 部 ， 会 有 设置 存储 策略 的 动作 : 





static HdfsFileStatus startFilel( 
FSNamesystem fsn, FSPermissionChecker pc, String srcy 
PermissionStatus permissions, String holder, String clientMachine, 
EnumSet<CreateFlag> flag, boolean createParent, 
short replication, long blockSize, 
EncryptionKeyInfo ezInfo, INode.BlocksMapUpdateInfo toRemoveBlocks, 
boolean logRetryEntry) 
throws IOException { 
assert fsn.hasWriteLock(); 


boolean create = flag.contains (CreateFlag.CREATE); 
boolean overwrite = flag.contains (CreateFlag .OVERWRITE); 

// 判断 CreateFlag 是 否 带 有 LAZY_PERSIST 标 识 ， 来 判断 是 否 是 内 存 存储 策略 
boolean isLazyPersist = flag.contains (CreateFlag.LAZY PERSIST); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/1 
// 在 此 设置 策略 
setNewINodeStoragePolicy (fsd.getBlockManager (), newNode, iip, 
isLazyPersist); 

fsd.getEditLog () .logOpenFile (src, newNode, overwrite, logRetryEntry); 
if (NameNode.stateChangeLog.isDebugEnabled()) { 

NameNode. stateChangeLog.debug ("DIR* NameSystem.startFile: added " + 

src + " inode " + newNode.getId() + " " + holder); 


} 
return FSDirStatAndListingOp.getFileInfo (fsd, src, false, isRawPath); 


6100/0EBPS/Text/... 











这 部 分 的 过 程 调 














见 





DFSClient#create with CreateFlag FSNamesystem#startFile BE ta 


FSDirWriteFileOp#setNewlNodeStoragePolicy FSDirWriteFileOp#startFile 








图 1-2 LAZY_PERSIST 策 略 设 置 流程 











还 有 一 种 方法 是 通过 FileSystem 的 setStoragePolicy 方 法 ， 不 过 此 方法 在 还 未 发 布 的 2.8 版 本 中 提供 ， 如 下 所 示 : 





fs.setStoragePolicy (path, "LAZY PERSIST"); 





这 种 方式 的 优点 在 于 可 以 用 程序 动态 地 设置 目标 路 径 的 存储 方式 。 
以 上 就 是 存储 策略 的 设置 过 程 ， 这 一 部 分 还 是 非常 直接 明了 的 。 
2.LAZY_PERSIST 内 存 存 储 
当 我 们 为 文件 设置 了 LAZY_PERSIST 的 存储 方式 之 后 ，DataNode 如 何 进行 内 存 式 的 存储 呢 ? 笔者 在 下 面 会 分 模块 、 分 角色 进行 介绍 。 


首先 要 介绍 的 是 LAZY_PERSIST 相 关 结 构 。 在 之 前 的 内 容 中 已 经 提 到 过 ， 在 数据 存储 的 同时 会 有 另外 一 批 数据 被 异步 地 持久 化 ， 所 以 这 里 一 定 会 涉及 多 个 服务 对 象 的 合作 。 这 些 服 务 对 象 的 指挥 者 是 
FsDatasetImpl， 它 是 一 个 管理 DataNode 所 有 磁盘 读 写 的 管家 。 








在 FsDatasetlmpl 中 ， 与 内 存 存储 相关 的 服务 对 象 有 3 个 ， 如 图 1-3 所 示 。 











FsDatasetImpl 


RamDiskReplicaLruTracker RamDiskAsyncLazyPersistService [AVA 





图 1-3 LAZY_PERSIST 相 关 服 务 对 象 
说 明 如 下 : 


“ RamDiskAsyncLazyPersistService: 此 对 象 是 异步 持久 化 线程 服务 ， 针 对 每 一 个 磁盘 块 设置 一 个 对 应 的 线程 池 ， 需 要 持久 化 到 给 定 磁盘 的 数据 块 会 被 提交 到 对 应 的 线程 池 中 去 。 每 个 线程 池 的 最 大 线程 数 
为 1。 


“LazyWrtiter: 这 是 一 个 线程 服务 ， 此 线程 会 不 断 地 从 数据 块 列表 中 取出 数据 块 ， 将 数据 块 加 入 到 异步 持久 化 线程 池 RamDiskAsyncLazyPersistService 中 去 执行 。 


“ RamDiskReplicaLruTracker: 是 副本 块 跟 踪 类 ， 此 类 中 维护 了 所 有 已 持久 化 、 未 持久 化 的 副本 以 及 总 副本 数据 信息 。 所 以 当 一 个 副本 被 最 终 存储 到 内 存 中 后 ， 相 应 地 会 有 副本 所 属 队列 信息 的 变更 。 当 
节点 内 存 不 足 时 ， 会 将 最 近 最 少 被 访问 的 副本 块 移 除 。 





以 上 3 者 的 紧密 合作 ， 最 终 实现 HDFS 的 内 存 存 储 。 下 面 是 具体 的 角色 介绍 。 
(1) RamDiskReplicaLruTracker 


RamDiskReplicaLruTracker 起 到 了 一 个 中 间 人 的 角色 ， 它 内 部 维护 了 多 个 关系 的 数据 块 信息 ， 主 要 是 以 下 3 类 : 





public class RamDiskReplicaLruTracker extends RamDiskReplicaTracker { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// blockpool Id 对 副本 信息 的 映射 图 
Map<String, Map<Long, RamDiskReplicaLru>> replicaMaps; 


// 待 写 入 磁盘 的 副本 队列 

Queue<RamDiskReplicaLru> replicasNotPersisted; 

// 已 持久 化 写 入 磁盘 的 映射 图 

TreeMultimap<Long, RamDiskReplicaLru> replicasPersisted; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





这 里 的 Queue<RamDiskReplicaLru> 就 是 待 存 入 内 存 存储 队列 。 以 上 3 个 变量 之 间 的 关系 见 图 1-4。 





replicaMaps 


persisted 


replicasNotPersisted 3 replicasPersisted 





图 1-4 RamDisk 副 本 块 结构 关系 图 
RamDiskReplicaLruTracker 中 的 方法 操作 绝 大 多 数 与 这 3 个 变量 的 增删 改动 相关 ， 所 以 逻辑 并 不 复杂 ， 我 们 只 需要 了 解 这 些 方法 有 什么 作用 即 可 。 笔 者 将 方法 分 成 了 以 下 两 类 : 
第 一 类 ， 异 步 持久 化 操作 相关 方法 。 如 图 1-5 所 示 。 





addReplica 







dequeueNextReplicaToPersist 


reenqueueReplicaNotPersisted 


recordStartLazyPersist 


如 果 失 败 


eolel elle :ra A 


图 1-5 异步 持久 化 操作 相关 流程 图 


当 节 点 重启 或 者 有 新 的 文件 设置 了 LAZY_PERSIST 策 略 后 ， 就 会 有 新 的 副本 块 存储 到 内 存 中 ， 同 时 会 加 入 到 replicaNotPersisted 队 列 中 。 经 过 中 间 的 dequeueNextReplicaToPersist 方 法 ， 取 出 下 一 个 


将 被 持久 化 的 副本 块 ， 进 行 写 磁盘 的 操作 。 在 持久 化 的 过 程 中 将 调用 recordStartLazyPersist、recordEndLazyPersist 这 两 个 方法 ， 标 志 着 持久 化 状态 的 变更 。 


第 二 类 ， 异 步 持久 化 操作 无 直接 关联 方法 。 方 法 如 下 : 
1) discardReplica: 当 检测 到 不 再 需要 某 副 本 的 时 候 (包括 副本 已 被 删除 ， 或 已 损坏 的 情况 ) ， 可 以 从 内 存 中 移 除 、 撤 销 副 本 。 


2) touch: 恰好 与 Linux 中 的 touch 命 令 同 名 ， 此 方法 意味 着 访问 了 一 次 某 特定 的 副本 块 ， 并 会 更 新 此 副本 块 的 lastUesdTime (最 近 一 次 使 用 时 间 ) 。lastUesdTime 会 在 后 面 提 到 的 LRU 算 法 中 起 到 关 


键 的 作用 。 





3) getNextCandidateForEviction: 此 方法 在 DataNode 内 存 空间 不 足 ， 需 要 内 存 额 外 预 留 出 空间 给 新 的 副本 块 时 被 调用 。 此 方法 会 根据 所 设置 的 eviction scheme 模 式 ， 选 择 需要 被 移 除 的 块 ， 默 认 











的 策略 模式 是 LRU 策 略 。 


这 里 反复 提 到 一 个 名 词 LRU，LRU 的 全 称 是 Least Recently Used， 意 为 最 近 最 少 使 用 算法 。getNextCandidateForEviction 方 法 采用 此 算法 的 好 处 是 保证 了 现 有 副本 块 的 一 个 活跃 度 ， 把 最 近 很 久 没有 


访问 过 的 块 给 移 除 掉 。 对 于 这 个 操作 ， 我 们 有 必要 了 解 其 中 的 细节 。 


首先 touch 方 法 会 更 新 副本 块 最 近 访问 的 时 间 : 





synchronized void touch (final String bpid, 
final long blockId) 1{ 
Map<Long, RamDiskReplicaLru> map = replicaMaps.get (bpid); 
RamDiskReplicaLru ramDiskReplicaLru = map.get (blockId); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 更 新 最 近 访 问 时 间 鹤 ， 并 重新 插入 数据 

if (replicasPersisted.remove (ramDiskReplicaLru.lastUsedTime, ramDiskReplicaLru)) { 
ramDiskReplicaLru.lastUsedTime = Time.monotonicNow (); 
replicasPersisted.put (ramDiskReplicaLru.lastUsedTime, ramDiskReplicaLru); 


} 
// 第 二 步 获取 候选 移 除 块 
synchronized RamDiskReplicaLru getNextCandidateForEviction() { 
// 获取 replicasPersisted 从 代 器 进行 遍历 
final Iterator<RamDiskReplicaLru> it = replicasPersisted.values () .iterator () 7 
while (it.hasNext()) { 
// 因为 replicasPersisted 已 经 根据 时 间 排 好 序 了 ， 所 以 取出 当前 的 块 进行 移 除 即 可 
final RamDiskReplicaLru ramDiskReplicaLru = it.next (); 
it.remove () 7 








Map<Long, RamDiskReplicaLru> replicaMap = 
replicaMaps .get (ramDiskReplicaLru.getBlockPoolId()); 


if (replicaMap != null && replicaMap.get (ramDiskReplicaLru.getBlockId()) != null) { 
return ramDiskReplicaLru; 
} 


// 如 果 副 本 不 存在 ， 则 继续 下 一 个 副本 
} 
return null; 


} 











这 里 比较 有 意思 的 是 ， 根 据 已 持久 化 块 的 访问 时 间 来 进行 筛选 移 除 ， 而 不 是 直接 在 内 存 块 对 象 中 记录 访问 时 间 ， 然 后 进行 排序 和 移 除 。 最 后 在 内 存 中 移 除 与 候选 块 属于 同一 副本 信息 的 块 并 释放 内 存 空 








间 : 





// 从 内 存 中 移 除 副本 块 信息 直到 满足 需要 字 节 数 的 大 小 
public void evictBlocks (long bytesNeeded) throws IOException { 
int iterations = 0; 





final long cacheCapacity = cacheManager.getCacheCapacity (); 
// 当 检 测 到 内 存 空间 不 满足 外 界 需要 的 大 小 时 
while (iterations++ < MAX BLOCK EVICTIONS PER ITERATION && 
(cacheCapacity - cacheManager.getCacheUsed()) < bytesNeeded) { 
// 获取 待 移 除 副 本 信息 


RamDiskReplica replicaState = ramDiskReplicaTracker.getNextCandidate ForEviction(); 


if (replicaState == null) { 
break; 
} 


if (LOG.isDebugEnabled()) { 
LOG.debug ("Evicting block " + replicaState); 
} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 移 除 内存 中 的 相关 块 并 释放 空间 
removeOldReplica (replicaInfo，newReplicaInfo，blockFile，metaFiley 
blockFileUsed, metaFileUsed, bpid); 
} 
} 





(2) LazyWriter 





LazyWriter 是 一 个 线程 服务 ， 它 是 一 个 发 动机 ， 循 环 不 断 地 从 队列 中 取出 待 持久 化 的 数据 块 ， 提 交 到 异步 持久 化 服务 中 去 。 其 中 








要 的 run 方 法 如 下 所 示 : 





public void run() { 
int numSuccessiveFailures = 0; 


while (fsRunning && shouldRun) { 
try { 
// 取出 新 的 副本 块 并 提交 到 异步 服务 中 ， 返 回 是 否 提交 成 功 的 布尔 值 


numSuccessiveFailures = saveNextReplica() ? 0 : (numSuccessiveFailures + 1); 


// 如 果 所 有 的 持久 化 操作 失败 ， 则 进行 睡眠 等 待 ， 避 免 短 时 间 内 连续 的 重 试 

if (numSuccessiveFailures >= ramDiskReplicaTracker.numReplicas NotPersisted()) { 
Thread. sleep (checkpointerInterval * 1000); 
numSuccessiveFailures = 0; 








} 
} catch (InterruptedException e) { 
LOG.info("LazyWriter was interrupted, exiting"); 


break; 
} catch (Exception e) { 
LOG.warn ("Ignoring exception in LazyWriter:", e); 





之 后 ， 进 入 saveNextReplica 方 法 的 处 理 : 





Private boolean saveNextReplica() { 
RamDiskReplica block = null; 
FsVolumeReference targetReference; 
FsVolumeImpl targetVolume; 
ReplicaInfo replicaInfo; 
boolean succeeded = false; 


try { 
// 从 队列 中 取出 新 的 待 持 久 化 的 块 
block = ramDiskReplicaTracker.dequeueNextReplicaToPersist (); 
if (block != null) { 
synchronized (FsDatasetImpl.this) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 提交 到 异步 服务 中 去 
asyncLazyPersistService.submitLazyPersistTask( 
block.getBlockPoolId(), block.getBlockId(), 


replicaInfo.getGenerationStamp(), block.getCreationTime(), 
replicaInfo.getMetaFile(), replicaIinfo.getBlockFile(), 
targetReference); 


} 
} 
} 
succeeded = true; 
} catch (IOException ioe) { 
LOG.warn ("Exception saving replica " + block, ioe); 


} finally { 
if (!succeeded && block != null) { 
LOG.warn ("Failed to save replica " + block + ". re-enqueueing it."); 


// 进行 副本 块 提交 失败 处 理 ， 此 副本 块 将 会 再 次 提交 到 待 持久 化 队列 中 
onFailLazyPersist (block.getBlockPoolId(), block.getBlockId()); 
} 
: 


return succeeded; 








LazyWriter 线 程 服务 的 流程 图 可 以 归纳 为 图 1-6。 


vA RamDiskReplicaTracker#dequeueNextReplicaToPersist 


saveNextReplica 


RamDiskAsyncLazyPersistService#submitLazyPersistTask 

















1-6 LazyWritet 服 务 流程 

















我 们 结合 LazyWriter 和 RamDiskReplicaTracker 跟 踪 服务 ， 就 可 以 得 到 下 面 一 个 完整 的 流程 (暂且 不 考虑 RamDiskAsyncLazyPersistService 的 内 部 执行 ) ， 如 图 1-7 所 示 。 
(3) RamDiskAsyncLazyPersistService 

最 后 一 部 分 异步 服务 的 内 容 相 对 就 比较 简单 了 ， 主 要 围绕 着 Volume 磁 盘 和 Executor 线 程 池 这 两 部 分 的 内 容 ， 秉 持 着 下 面 一 个 原则 : 

一 个 磁盘 服务 对 应 一 个 线程 池 ， 并 且 一 个 线程 池 的 最 大 线程 数 也 只 有 1 个 。 


线程 池 列 表 定 义 如 下 : 





RamDiskReplicaTracker 





LazyWriter 


RamDiskReplicaLru 


插入 队列 


RamDiskReplicaLru RamDiskAsyncLazyPersistService 























到 


1-7 异步 持久 化 流程 























class RamDiskAsyncLazyPersistService { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
private Map<File, ThreadPoolExecutor> executors 
= new HashMap<File, ThreadPoolExecutor>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








这 里 的 File 代 表 一 个 磁盘 上 的 目录 ， 个 人 认为 这 里 完全 可 以 用 String 字 符 串 蔡 代 。 既 可 以 减少 存储 空间 ， 又 直观 明了 。 从 这 里 可 以 看 出 磁盘 服务 与 线程 池 一 对 一 的 关系 了 。 








当 服 务 启动 的 时 候 ， 就 会 有 新 的 磁盘 目录 加 入 ， 如 下 代码 所 示 : 





synchronized void addVolume (File volume) { 
if (executors == null) { 
throw new RuntimeException("AsyncLazyPersistService is already shutdown"); 
. 
ThreadPoolExecutor executor = executors.get (volume); 
// 如 果 当 前 已 存在 此 磁盘 目录 对 应 的 线程 池 ， 则 抛 异常 
if (executor != null) { 
throw new RuntimeException("Volume " + volume + " is already existed."); 


} 
// 否则 进行 添加 


addExecutorForVolume (volume); 





之 后 ， 进 入 addExecutorForVolume 方 法 : 





Private void addExecutorForVolume (final File volume) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 新 建 线程 池 ， 最 大 线程 执行 数 为 1 
ThreadPoolExecutor executor = new ThreadPoolExecutor( 

CORE THREADS PER _ VOLUME， MAXIMUM THREADS PER _ VOLUMEP， 
THREADS KEEP ALIVE SECONDS，TimeUnit.SECONDS， 
new LinkedBlockingOueue<Runnable>(), threadFactory); 


executor.allowCoreThreadTimeOut (true); 
// 加 入 到 executors 中 ， 以 volume 作 为 key 
executors.put (volume, executor); 





还 有 一 个 需要 注意 的 地 方 是 提交 执行 方法 submitLazyPersistTask， 如 下 所 示 : 





void submitLazyPersistTask (String bpId, long blockId, 
long genStamp, long creationTime, 
File metaFile, File blockFile, 
FsVolumeReference target) throws IOException { 
if (LOG.isDebugEnabled()) { 
LOG.debug ("LazyWriter schedule async task to Persist RamDisk block pool id: " 
+ bpId + " block id: " + blockId); 


上 

// 获取 需要 持久 化 的 目标 磁盘 实例 

FsVolumeImp1 volume = (FEsVolumeImp1)target.getVolume () 

File lazyPersistDir = Volume.getLazyPersistDir (bpId) 7 

if (!lazyPersistDir.exists() && !lazyPersistDir.mkdirs()) { 
FsDatasetImpl .LOG.warn ("LazyWriter failed to create " + lazyPersistDir); 
throw new IOException ("LazyWriter fail to find or create lazy persist dir: 

+ lazyPersistDir.toString()); 


> 

// 新 建 此 服务 Task 

ReplicaLazyPersistTask lazyPersistTask = new ReplicaLazyPersistTask( 
bpId, blockId, genStamp, creationTime, blockFile, metarFile, 
target, lazyPersistDir); 

// 提交 到 对 应 volume 的 线程 池 中 执行 


execute (volume .getCurrentDir(), lazyPersistTask); 





如 果 在 上 述 执行 的 过 程 中 发 生 失 败 ， 会 调用 失败 处 理 的 方法 ， 并 会 重新 将 此 副本 块 插入 到 replicateNotPersisted 队 列 中 ， 等 待 下 一 次 的 持久 化 : 








public void onFailLazyPersist (String bpId, long blockId) { 
RamDiskReplica block = null; 
block = ramDiskReplicaTracker.getReplica (bpId, blockId); 
if (block != null) { 
LOG.warn ("Failed to save replica " + block + ". re-enqueueing it."); 
// 重新 插入 队列 操作 
ramDiskReplicaTracker .reenqueueReplicaNotPersisted (block); 
} 
} 

















其 他 如 removeVolume 等 方法 实现 比较 简单 ， 这 里 不 做 过 多 介绍 。 图 1-8 是 RamDisk-AsyncLazyPersistService 总 的 结构 图 。 


以 上 3 部 分 描述 了 LAZT_PERSIST 下 的 队列 式 内 存 数据 块 持久 化 服务 、 异 步 持久 化 服务 的 内 部 运行 逻辑 和 LRU 预 留 内 存 空间 算法 策略 。 
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图 1-8 RamDiskAsyncLazyPersistService 相 关 结 构图 


1.1.4 LAZY_PERSIST 内 存 存储 的 使 用 


介绍 完 原理 部 分 之 后 ， 下 面 介 绍 具 体 的 配置 使 用 。 
第 一 步 ， 要 使 用 LAZY_PERSIST 内 存 存储 策略 ， 需 要 有 对 应 的 存储 介质 ， 内 存 存储 介质 对 应 的 类 型 是 RAM_DISK。 


在 使 用 RAM_DISK 之 前 ， 需 要 完成 虚拟 内 存盘 的 配置 工作 ， 这 里 以 tmpfs 文 件 系统 为 例 进行 介绍 。 在 默认 情况 下 ，tmpfs 是 被 挂 载 到 /devshm， 并 且 大 小 是 32GB。 也 就 是 说 ， 在 此 目录 下 的 数据 实质 上 
是 存在 于 内 存 中 的 。 但 是 有 的 时 候 ， 我 们 可 能 会 想 挂 载 到 自己 想 要 挂 载 的 目录 下 ， 而 且 我 们 也 想 对 内 存 的 使 用 大 小 进行 有 效 的 控制 ， 可 以 使 用 下 面 的 命令 进行 这 2 方面 的 设置 : 





sudo mount -t tmpfs -o size=16g tmpfs /mnt/dn-tmpfs/ 





以 上 操作 的 意思 是 将 tmpfs 挂 载 到 目录 /mnt/dn-tmpfs， 并 且 限 制 内 存 使 用 大 小 为 16GB。 最 后 ， 建 议 在 /etc/fstab 文 件 中 将 这 层 挂 载 关 系 写 入 ， 这 可 以 让 机 器 在 重启 之 后 自动 创建 好 挂 载 关 系 。 























首先 需要 将 机 器 中 已 经 完成 好 的 虚拟 内 存盘 配置 到 dfs.datanode.data.dir 中 ， 其 次 还 要 带 上 RAM_DISK 标 签 ， 以 此 表明 此 目录 对 应 的 存储 介质 为 RAM_DISK， 配 置 样 例如 下 : 














<property> 

<name>dfs.datanode.data.dir</name> 

<value>/grid/0, /grid/1, /grid/2, [RAM DISK] /mnt/dn-tmpfs</value> 
</property> 





注意 ， 这 个 标签 是 必须 要 打上 的 ， 否 则 HDFS 默 认 的 都 是 DISK。 


第 二 步 就 是 设置 具体 的 文件 策略 类 型 。 
+ 总 


: 确保 HDEFS 异 构 存 储 策略 没有 被 关闭 ， 默 认 是 开启 的 ， 配 置 项 是 dfs.storage.policy.enabled。 


确认 dfs.datanode.max.locked.memotry 是 否 设置 了 足够 大 的 内 存 值 ， 是 否 已 是 DataNode 能 承受 的 最 大 内 存 大 小 。 内 存 值 过 小 会 导致 内 存 中 的 总 的 可 存储 的 数据 块 变 少 ， 但 如 果 超 过 DataNode 能 承受 的 最 大 


内 存 大 小 的 话 ， 部 分 内 存 块 会 被 直接 移出 。 


FsDatasetAsyncDiskService 


在 FsDatasetImpl| 类 中 ， 还 有 一 个 与 内 存 存 储 异步 持久 化 相 类 似 的 服务 FsDataset-AsyncDiskService。 在 类 的 实现 逻辑 上 ， 该 服务 与 RamDiskAsyncLazyPersistService 有 许多 相似 之 处 ， 同 样 包 含 许多 








执行 线程 池 ， 并 且 每 个 线程 池 对 应 一 个 存储 目录 。 不 过 在 具体 的 执行 内 容 上 ， 它 主要 做 两 类 异步 任务 : 


: 文件 目录 的 异步 删除 。 


“ 异步 执行 SyncFileRange 请 求 操作 。SyncFileRange 的 全 称 是 sync a file segment with disk， 它 的 作用 在 于 数据 做 多 次 更 新 后 ， 对 其 进行 一 次 性 的 写 出 ， 提 高 IO 的 效率 。 

















FsDatasetAsyncDiskService 类 位 于 包 org.apache.hadoop.hdfs.server.datanode.fsdataset.imp| 下 ， 感 兴趣 的 读者 可 以 自行 研究 。 


























在 HDFS 异 构 存储 方式 中 ， 除 了 内 存 存 储 之 外 ， 其 实 还 有 另外 一 类 存储 方式 也 尤为 重要 ， 就 是 HDFS 的 Archival Storage。Archival Storage 指 的 是 一 种 高 密度 的 存储 方式 ， 以 此 解决 集群 数据 规模 增长 






































带 来 的 存储 空间 不 足 的 问题 。 通 常用 于 Archival Storage 的 节点 不 需要 很 好 的 计算 性 能 ， 一 般 用 于 冷 数 据 的 存储 。HDFS 的 Archival Storage 的 具体 设计 与 实现 ， 可 以 参阅 相关 JIRA，HDFS-6584 (Support 








Archival Storage) 。 


1.2 ”HDFS 异 构 存 储 

















Hadoop 在 2.6.0 版 本 中 引入 了 一 个 新 特性 : 异 构 存储 。 异 构 存储 关键 在 于 “ 异 构 ” 两 个 字 。 异 构 存储 可 以 根据 各 个 存储 介质 读 写 特 性 的 不 同 发 挥 各 自 的 优势 。 一 个 很 适用 的 场景 就 是 上 节 提 到 的 冷 热 数 


















































据 的 存储 。 针 对 冷 数据 ， 采 用 容量 大 的 、 读 写 性 能 不 高 的 存储 介质 存储 ， 比 如 最 普通 的 磁盘 。 而 对 于 热 数据 而 言 ， 可 以 采用 SSD 的 方式 进行 存储 ， 这 样 就 能 保证 高 效 的 读 性 能 ， 在 速率 上 甚至 能 做 到 十 倍 或 
百倍 于 普通 磁盘 的 读 写 速度 。 换 句 话说 ，HDFS 异 构 存储 特性 的 出 现 使 得 我 们 不 需要 搭建 2 套 独立 的 集群 来 存放 冷 热 2 类 数据 ， 在 一 套 集群 内 就 能 完成 。 所 以 这 个 功能 还 是 有 非常 大 的 实用 价值 的 。 本 节 就 带 
领 大 家 全 面 了 解 HDFS 的 异 构 存储 ， 包 括 异 构 存储 的 类 型 、 存 储 策略 、HDFS 如 何 做 到 智能 化 的 异 构 存储 等 。 




















1.2.1” 异 构 存储 类 型 


以 下 是 在 HDFS 中 声明 的 Storage Type: 
* RAM_DISK 

“SSD 

"DISK 


' ARCHIVE 






































实 就 是 内 存 ， 而 ARCHIVE 并 没有 特 指 哪 种 存储 介质 ， 主 要 指 的 是 高 密度 存储 介质 ， 上 











HDFS 中 定义 了 这 4 种 异 构 存 储 类 型 ，SSD、DISK 一 看 就 知道 是 什么 意思 ， 这 里 看 一 下 其 余 的 两 个 。RAM_DISK 











解决 数据 扩容 的 问题 。 这 4 种 类 型 定义 在 StorageType 类 中 ， 如 下 所 示 : 


Public enum StorageType { 
/根据 存储 的 速度 ”从 供 到 慢 
RAM DISK (true), 
SSD (false)， 
DISK (false), 
ARCHIVE (false); 
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其 中 true 或 者 false 代 表 此 类 存储 类 型 是 否 为 transient 特 性 。transient 的 意思 是 转瞬 即 逝 的 ， 并 非 持久 化 的 。 在 上 述 4 类 介质 中 ， 只 有 内 存 存 储 才 是 transient 特 性 的 。 在 HDFS 中 ， 如 果 没 有 主动 声明 数 








局 目录 存储 类 型 ， 默认 都 是 DISK 类 型 。 这 4 类 存储 介质 之 间 一 个 很 大 的 区 别 在 于 读 写 速度 ， 从 上 到 下 依次 减 慢 。 所 以 将 热 数 据 存在 内 存 中 或 是 SSD 中 会 是 不 错 的 选择 ， 而 将 冷 数据 存放 于 DISK 和 ARCHIVE 类 


























型 的 介质 中 会 更 好 。 在 HDFS 中 ，StorageType 的 设 定 非常 重要 。 那 么 如 何 让 HDFS 知 道 集 群 中 的 数据 存储 目录 分 别 是 哪 种 类 型 的 存储 介质 呢 ? 这 就 需要 在 配置 属性 时 主动 声明 ，HDFS 并 没有 自动 检测 识别 
的 功能 。 配 置 属性 dfs.datanode.data.dir 可 以 对 本 地 对 应 存储 目录 进行 设置 ， 同 时 带 上 一 个 存储 类 型 标签 ， 声 明 此 目录 用 的 是 哪 种 类 型 的 存储 介质 ， 例 子 如 下 : 









































[SSD]file:///grid/dn/ssd0 











网 














如 果 目 录 前 没有 带 上 [SSD]/[DISK]/[ARCHIVE]/[RAM_DISK] 这 4 种 类 型 中 的 任何 一 种 ， 则 默认 是 DISK 类 型 。 图 1-9 是 存储 介质 结构 图 。 








StorageType 


RAM_DISK ARCHIVE 





一 了 
速度 从 快 到 慢 


图 1-9 HDFS 存 储 介质 类 型 


1.2.2“ 异 构 存储 原理 
了 解 完 异 构 存储 类 型 后 ， 我 们 有 必要 了 解 一 下 HDFS 异 构 存储 的 实现 原理 。 本 节 会 结合 部 分 HDFS 源 码 进行 前 述 。HDFS 异 构 存储 可 总 结 为 以 下 三 点 : 
“ DataNode 通 过 心跳 汇报 自身 数据 存储 目录 的 StorageType 给 NameNode。 


“ 随后 NameNode 进 行 汇总 并 更 新 集群 内 各 个 节点 的 存储 类 型 情况 。 





“ 待 复制 文件 根据 自身 设 定 的 存储 策略 信息 向 NameNode 请 求 拥有 此 类 型 存储 介质 的 DataNode 作 为 候选 节 ， 








结合 部 分 源码 ， 来 一 步 步 跟踪 内 部 的 过 程 细节 。 


回 











从 以 上 3 点 来 看 ，HDFS 异 构 存储 原理 并 不 复杂 。 下 


1.DataNode 存 储 目录 汇报 








首先 是 数据 存储 目录 的 解析 与 心跳 汇报 过 程 。 在 FsDatasetlmpI 的 构造 函数 中 对 dataDir 进 行 存储 目录 的 解析 ， 生 成 了 storageType 的 List 列 表 : 

















// FsDatasetImple 初 始 构造 函数 
FsDatasetImpl (DataNode datanode，DataStorage storage, Configuration conf 


) throws IOException { 
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String[] dataDirs = conf.getTrimmedStrings (DFSConfigKeys.DFS DATANODE DATA DIR KEY); 
Collection<StorageLocation> dataLocations = DataNode.getStorageLocations (conf)7 
List<VolumeFailureInfo> volumeFailureInfos = getInitialVolumeFailureInfos( 
dataLocations, storage); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















真正 调用 的 是 DataNode 的 getStorageLocations 方 法 : 





public static List<StorageLocation> Dt St orage rocat ons (Configuration conf) { 
// 获取 dfs.datanode.data.dir 配 置 中 的 多 个 目录 地 址 字符 串 
Collection<String> rawLocations = 
conf .getTrimmedSstringCollection (DFS_DATANODE DATA DIR KEY); 
List<StorageLocation> locations = 
new ArrayList<StorageLocation> (rawLocations.size()); 


for (String locationstring : rawLocations) { 
final StorageLocation location; 
try { 

// 解析 为 对 应 的 StorageLocation 

location = StorageLocation.parse (locationstring); 

} catch (IOException ioe) { 

LOG.error ("Failed to initialize storage directory " + locationstring 

+ ". Exception details; " + ioe); 

// 此 处 忽略 异常 

continue; 

catch (SecurityException se) { 

LOG.error ("Failed to initialize storage directory " + locationString 

+ ". Exception details: " + se); 
// 此 处 忽略 异常 


continue; 


} 
// 将 解析 好 的 StorageLocation 加 入 到 列表 中 
locations.add (location); 


return locations; 


} 





当然 我 们 最 关心 如 何 解析 配置 并 最 终 得 到 对 应 存储 类 型 的 过 程 ， 即 下 面 这 行 操作 所 执行 的 内 容 : 





location = StorageLocation.parse (locationstring); 





StorageLocation 的 解析 方法 如 下 : 





public static StorageLocation parse (String rawLocation) 
throws IOException, SecurityException { 
// 采用 正则 匹配 的 方式 进行 解析 
Matcher matcher = regex.matcher (rawLocation); 
StorageType storageType = StorageType.DEFAULT; 
String location = rawLocation; 





if (matcher.matches()) { 
String classString = matcher.group(1); 
location = matcher.group (2); 
if (!classString.isEmpty()) { 
storageType = 
StorageType.valueOf (StringUtils.toUpperCase (classString)); 
: 


* 
return new StorageLocation (storageType, new Path(location) .toUri()); 





这 里 的 StorageType.DEFAULT 就 是 DISK， 在 StorageType 中 定义 如 下 : 





public static final StorageType DEFAULT = DISK; 





后 续 这 些 解析 好 的 存储 目录 以 及 对 应 的 存储 介质 类 型 会 加 入 到 storageMap 中 ， 如 下 所 示 : 





private void addVolume (Collection<StorageLocation> dataLocations, 
Storage.StorageDirectory sd) throws IOException { 
final File dir = sd.getCurrentDir () 7 
final StorageType storageType = 
getStorageTypeFromLocations (dataLocations, sd.getRoot ()); 
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synchronized (this) { 
VolumeMap .addqA11 (tempVolumeMap); 
storageMap.put (sd.getStorageUuid(), 
new DatanodeStorage (sd.getStorageUuid(), 
DatanodeStorage. State.NORMAL, 
storageType)); 
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storageMap 存 储 了 目录 到 类 型 的 映射 关系 ， 可 以 说 是 非常 细 粒 度 的 。 更 重要 的 是 ， 这 些 信息 会 被 DataNode 组 织 成 StorageReport 通 过 心跳 的 形式 上 报 给 NameNode。 于 是 就 来 到 了 第 一 阶段 的 下 : 








public StorageReport [] getStorageReports (String bpid) 
throws IOException { 
List<StorageReport> reports; 
synchronized (statsLock) { 
List<FsVolumeImpl> curVolumes = getVolumes(); 
reports = new ArrayList<> (curVolumes.size()); 
for (FsVolumeImpl volume : curVolumes) { 
try (FsVolumeReference ref = volume.obtainReference()) { 
// 获取 磁盘 存储 信息 ， 并 生成 磁盘 报告 实例 
StorageReport sr = new StorageReport (volume.toDatanodestorage(), 
false, 
Volume .getCapacity(), 
Volume .getDfsUsed(), 
Volume .getAvailable(), 
Volume .getBlockPoolUsed (bpid)); 
// 将 报告 实例 加 入 到 报告 列表 中 
reports.add (sr); 
} catch (ClosedChannelException e) { 
continue; 
. 
} 


‘ 

// 返回 报告 列表 

return reports.toArray (new StorageReport [reports.size()]); 
} 











以 上 是 StorageReport 的 组 织 过 程 ， 它 最 终 被 BPServiceActor 的 sendHeartBeat 调 用 ， 发 送 给 NameNode， 如 下 所 示 : 











HeartbeatResponse sendHeartBeat () throws IOException { 
// 获取 存储 类 型 情况 报告 
StorageReport[] reports = 
dn.getFSDataset () .getStorageReports (bpos.getBlockPoolId()); 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Sending heartbeat with " + reports.length + 
" Storage reports from service actor: " + this); 


} 
// 获取 坏 磁盘 数据 信息 
VolumeFailureSummary volumeFailureSummary = dn.getFSDataset () 
.getVolumeFailureSummary () 7 
int numFailedVolumes = VolumeFailureSummary != null ? 
volumeFailureSummary. FailedStorageLocations().length : 0; 
// 还 有 DataNode 自 身 的 存储 容量 信息 ， 最 后 发 送 给 NameNode 
return bpNamenode.sendHeartbeat (bpRegistration, 
reports, 
dn.getFSDataset () .getCacheCapacity()， 
dn.getFSDataset () .getCacheUsed (), 
dn.getXmitsInProgress ()， 
dn.getXceiverCount ()， 
numFailedVolumes, 
volumeFailureSummary); 














2. 存 储 心跳 信息 的 更 新 处 理 


现在 来 到 了 第 二 阶段 的 心跳 处 理 过 程 。 心 跳 处 理 在 DatanodeManager 的 handleHeartbeat 中 进行 : 





// 心跳 处 理 方法 
public DatanodeCommand[] handleHeartbeat (DatanodeRegistration nodeReg, 
StorageReport [] reports, final String blockPoolId, 
long cacheCapacity, long cacheUsed, int xceiverCount, 
int maxTransfers, int failedVolumes, 
VolumeFailureSummary volumeFailureSummary) throws IOException { 
synchronized (heartbeatManager) { 
synchronized (datanodeMap) { 
DatanodeDescriptor nodeinfo = null; 
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heartbeatManager .updateHeartbeat (nodeinfo, reports, 
cacheCapacity, cacheUsed, 
xceiverCount, failedVolumes, 
volumeFailureSummary); 
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最 终 在 heartbeatManager 中 会 调用 到 DatanodeDescription 对 象 的 updateHeartbeatState 方 法 ， 该 方法 会 更 新 Storage 的 信息 ， 如 下 所 示 : 

















// 处 理 心跳 中 统计 值 相 关 的 操作 
public void updateHeartbeatState (StorageReport [] reports, long cacheCapacity, 

long cacheUsed, int xceiverCount, int volFailures, 

VolumeFailureSummary volumeFailureSummary) { 
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for (StorageReport report : reports) { 

DatanodeStorageInfo storage = updateStorage (report .getStorage () ) 7 

if (checkFailedStorages) { 

failedStorageInfos.remove (storage); 
} 


storage.receivedHeartbeat (report); 

// 进行 统计 计数 的 更 新 统计 

totalCapacity += report.getCapacity (); 
totalRemaining += report.getRemaining(); 
totalBlockPoolUsed += report .getBlockPoolUsed(); 
totalDfsUsed += report.getDfsUsed(); 


} 
rollBlocksScheduled (getLastUpdateMonotonic()); 
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3. 目 标 存 储 介质 类 型 节点 的 请 求 


各 个 DataNode 心 跳 信息 都 更 新 完毕 之 后 ， 有 目标 存储 介质 需求 的 待 复制 文件 块 就 会 向 NameNode 请 求 DataNode， 这 部 分 处 理 在 FSNamesystem 的 getAdditionDatanode 中 进行 : 





// 获取 剩余 块 方法 

LocatedBlock getadditionalDatanode (String src, long filelId, 
final ExtendedBlock blk, final DatanodeInfo[] existings, 
final String[] storageIDs, 
final Set<Node> excludes, 
final int numAdditionalNodes, final String clientName 
) throws IOException { 
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final INodeFile file = checkLease (src, clientName, inode, fileId); 
clientMachine = file.getFileUnderConstructionFeature () .getClientMachine (); 
clientnode = blockManager .getDatanodeManager () .getDatanodeByHost (clientMachine); 
Preferredblocksize = file.getPreferredBlockSize () 7? 
// 获取 待 复制 文件 的 存储 策略 Id, 对 应 的 就 是 存储 策略 信息 类 型 
storagePolicyID = file.getStoragePolicyID () 7， 
// 寻找 存储 目录 信息 
final DatanodeManager dm = blockManager.getDatanodeManager () 7 

i 点 的 存储 目录 列表 信息 

chosen = Arrays.asList (dm.getDatanodeStorageInfos (existings, storageIDs)); 
} finally { 
readUnlock (); 
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// 选择 满足 需求 的 节点 


final DatanodeStorageInfo[] targets = blockManager.chooseTarget4AdditionalDatanode( 


src, numAdditionalNodes, clientnode, chosen, 

excludes, preferredblocksize, storagePolicyID); 
final LocatedBlock lb = new LocatedBlock (blk, targe 
blockManager .setBlockToken (lb, AccessMode.COPY); 
return 1b; 


ts); 











目标 存储 节点 信息 就 被 设置 到 了 具体 块 的 信息 中 。 这 里 的 target 类 型 为 Datanode-Storagelnfo， 代 表 的 是 DataNode 中 的 一 个 dataDir 存 储 目录 。 上 述 代码 中 具体 blockManager 如 何 根据 给 定 的 候选 


DatanodeStoragelnfo 存 储 目录 和 存储 策略 来 选择 出 目标 节点 ， 


getDataDir 


1.2.3 ” 块 存储 类 型 选择 策略 


在 现 有 的 HDFS 中 ， 我 们 可 以 对 块 的 网 络 拓 朴 位 置 进行 策略 的 选择 ， 同 样 ， 对 














就 是 下 一 节 将 要 有 








parseStorageLocation 








点 阐述 的 存储 介质 选择 策略 。 本 节 最 后 给 出 HDFS 的 异 构 存储 过 程 调 用 的 简单 流程 图 ， 如 图 1-10 所 示 。 


























snedHeartBeat 
StorageLocations NameNode 


DataNodeManager DatanodeDescriptor#StorageMap 





寻找 DataNode 存储 


BlockManager#ChooseTargetNodes 














提供 存储 策略 Id 


1-10 ” 蜡 构 存储 过 程 图 


数据 的 存储 介质 ，HDFS 也 有 对 应 的 若干 种 策略 。 对 于 一 个 完整 的 存储 类 型 选择 策略 ， 有 如 下 的 基本 信息 定义 : 





// 块 存储 类 型 选择 策略 对 象 
@InterfaceAudience.Private 
public class BlockStoragePolicy { 


public static final Logger LOG = LoggerFactory.getLogger (BlockStoragePolicy 


.Class); 


// 策略 唯一 标识 Id 
Private final byte id; 
// 策略 名 称 


private final String name; 


// 对 于 一 个 新 块 ， 存 储 副 本 块 的 可 选 存储 类 型 信息 组 
private final StorageType[] storageTypes; 

// 对 于 第 一 个 创建 块 ，fallback 情 况 时 的 可 选 存储 类 型 
private final StorageType[] creationFallbacks; 
// 对 于 块 的 其 余 副 本 ，fallback 情 况 时 的 可 选 存储 类 型 
private final StorageType[] replicationFallbacks; 





// 当 创 建文 件 的 时 候 ， 是 否 继承 祖先 目录 信息 的 策略 ， 主 要 用 于 主动 设置 策略 的 时 候 


Private boolean copyOnCreateFile; 
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这 里 出 现 了 fallback 的 情况 ， 什 么 叫做 fallback 的 情况 呢 ? 即 


相应 的 逻辑 代码 如 下 : 





当前 存储 类 型 不 可 

















的 时 候 ， 退 一 级 选择 使 




















的 存储 类 型 。 





public List<StorageType> chooseStorageTypes (final sho: 
final Iterable<StorageType> chosen, 
final EnumSet<StorageType> unavailables, 
final boolean isNewBlock) { 


rt replication, 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





forl(int i StorageT pes.size() =- 171i3= 0; i-=) { 
// 获取 当前 需要 的 存储 类 型 
final StorageType t = storageTypes.get (i); 


// 如 果 当 前 的 存储 类 型 是 在 不 可 用 的 存储 类 型 列表 中 ， 选 择 fallback 的 情况 


if (unavailables.contains(t)) { 


// 根据 是 否 为 新 块 还 是 普通 的 副本 块 ， 选 择 相 应 的 fallback 的 StorageType 


final StorageType fallback = isNewBlock? 
getCreationFallback (unavailables) 
: getReplicationFallback (unavailables); 
if (fallback == null) { 
removed.add (storageTypes .remove (i)); 
} else { 
storageTypes.set (i, fallback); 
} 
} 
} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 getFallback 方 法 中 会 选取 第 一 个 满足 条 件 的 fallback 的 StorageType: 





private static StorageType getFallback (EnumSet<StorageType> unavailables, 


StorageType[] fallbacks) { 
for (StorageType fb : fallbacks) { 
// 如 果 找 到 满足 条 件 的 StorageType， 立 即 返回 
if (!unavailables.contains (fb)) { 
return fb; 
} 


return null; 


} 























当然 这 些 都 只 是 单一 的 存储 类 型 选择 策略 。HDFS 在 使 用 的 时 候 也 不 是 新 建 一 个 StoragePolicy 对 象 直接 调用 ， 而 是 从 BlockStoragePolicySuite 策 略 集合 中 获取 策略 。 


























1.2.4” 块 存储 策略 集合 


块 存储 策略 集合 是 BlockStoragePolicySuite。 在 此 类 内 部 定义 了 6 种 策略 ， 不 仅仅 分 为 冷 热 数 据 两 种 类 型 ， 其 详细 策略 描述 可 见 源 代码 中 的 解释 。 类 策略 名 称 如 下 : 
:HOT 

COLD 

WARM 

:ALL_ SSD 

“ONE_SSD 


* LAZY_PERSIST 








区 分 的 。 策 略 倒是 划分 出 来 了 ， 但 是 这 些 不 同 的 策略 之 间 














区 分 的 ， 后 三 种 策略 是 根据 存放 盘 的 性 质 来 




















在 这 6 种 策略 中 ， 前 三 种 策略 和 后 三 种 策略 可 以 看 作 是 两 大 类 。 前 三 种 策略 是 根据 冷 热 数据 的 角度 来 
区 


的 主要 区 别 在 哪里 呢 ， 答 案 就 是 候选 存储 类 型 组 。 











在 创建 BlockStoragePolicySuite 的 时 候 ， 对 这 些 策略 都 进行 了 构造 ， 如 下 所 示 : 





// 块 存储 策略 集 的 构造 初始 化 
public static BlockStoragePolicySuite createDefaultSuite() { 
final BlockStoragePolicy[] policies = 
new BlockStoragePolicy[1 << ID BIT LENGTH]; 
final byte lazyPersistId = HdfsConstants.MEMORY STORAGE POLICY ID; 
//_LAZY_PERSIST 策 略 构造 加 
policies[lazyPersistId] new BlockStoragePolicy (lazyPersistId, 
HdfsConstants .MEMORY STORAGE POLICY NAME, 
new StorageType[] {StorageType.RAM DISK, StorageType.DISK}, 
new StorageType[] {StorageType.DISK}, 
new StorageType[] {StorageType.DISK}, 
true); // Cannot be changed on regular files, but inherited. 
final byte allssdId = HdfsConstants.ALLSSD STORAGE POLICY ID; 
//_ALL_SSD 策 略 构造 


policies[allssdId] 
HdfsConstants .AL 
new StorageType 
new StorageType 
new StorageType 
final byte onessdId 
//_ONE_SSD 策 略 构造 
policies[onessdIg] 


new BlockStoragePolicy (allssdId, 
LSSD_STORAGE POLICY NAME, 
{StorageType.SSD}, 
{StorageType.DISK}, 
{StorageType.DISK}); 
= HdfsConstants.ONESSD STORAGE POLICY _ID; 


new BlockStoragePolicy (onessdId, 


HdfsConstants .ONESSD STORAGE POLICY NAME, 


new StorageType 
new StorageType 
new StorageType 


{StorageType.SSD, StorageType.DISK}, 
{StorageType.SSD, StorageType.DISK}, 
{StorageType.SSD, StorageType.DISK}); 


final byte hotId = HdfsConstants.HOT STORAGE POLICY _ID; 


//_HOT 策 略 构造 
policies [hotId] 


ne 


w BlockStoragePolicy (hotId, 


HdfsConstants.HOT STORAGE POLICY NAME., 


new StorageType 

new StorageType 
final byte warmId = 
//_WARM 策 略 构造 


{StorageType. DISK}, StorageType.EMPTY ARRAY, 
{StorageType.ARCHIVE}); 
HdfsConstants .WARM STORAGE POLICY ID; 


policies[warmId] = new BlockStoragePolicy (warmId, 
HdfsConstants .WARM STORAGE POLICY NAME, 


new StorageType 

new StorageType 

new StorageType 
final byte coldId = 
//_CLOD 策 略 构造 


{StorageType.DISK, StorageType.ARCHIVE}, 
{StorageType.DISK, StorageType.ARCHIVE}, 
{StorageType.DISK, StorageType.ARCHIVE}); 
HdfsConstants.COLD STORAGE POLICY ID; 


policies[coldId] = new BlockStoragePolicy (coldId 
HdfsConstants.COLD STORAGE POLICY NAME, 





new StorageType 





{StorageType. ARCHIVE)}, StorageType.EMPTY ARRAY， 


StorageType.EMPTY ARRAY); 
return new BlockStoragePolicySuite (hotId, policies); 





在 这 些 策略 对 象 的 参数 中 ， 第 三 个 参数 起 决定 性 作用 ， 
StorageType: 























因为 第 三 个 参数 会 被 返回 给 副本 块 作为 候选 存储 类 型 。 在 storageTypes 参 数 中 ， 有 了 时 可 能 只 有 1 个 类 型 声明 ， 例 如 ALL_SSD 策 略 只 有 如 下 





new StorageType[] {StorageType.SSD} 





而 ONE_SSD 却 有 两 个 : 





new StorageTypel[ 


{StorageType.SSD, StorageType.DISK} 














这 里 面 其 实 是 有 原因 的 。 








为 块 有 多 副本 机 制 ， 每 个 策略 要 为 所 有 的 副本 都 返回 相应 的 StorageType， 如 果 副 本 数 超过 候选 的 StorageType 数 组 时 应 怎么 处 理 ， 答 案 在 下 面 这 个 方法 中 : 





public List<StorageType> chooseStorageTypes (final short replication) { 


final List<StorageType> types 


int i = 0, j=0; 


new LinkedList<StorageType>(); 





// 从 前 往 后 依次 





匹配 存储 类 型 与 对 应 的 副本 下 标 相 


匹配 ， 同 时 要 过 滤 掉 





// transient 属 性 的 存储 类 型 
for (;i < replication && j < storageTypes.length; ++j) { 
if (!storageTypes[j].isTransient()) { 
types.add (storageTypes[j]); 


二 Hi 
} 


// 获取 最 后 一 个 存储 类 型 ， 统 一 作为 多 余 副 本 的 存储 类 型 


final StorageType last 
(!last.isTransient ()) { 


if 


storageTypes[storageTypes.length - 1]; 


for (; i < replication; i++) { 


types.add (last); 
} 
} 


return types; 








这 样 的 话 ，ONE_SSD 就 必然 只 有 第 一 个 块 的 副本 块 是 此 类 型 的 ， 其 余 副本 则 是 DISK 类 型 存储 ， 而 ALL_SSD 则 将 会 全 部 是 SSD 的 存储 。 图 1-11 给 出 存储 策略 集合 的 结构 图 。 





MEMORY_STORAGE_POLICY 


ALLSSD STORAGE POLICY 快 





ONESSD STORAGE POLICY 





存储 策略 速度 


HOT_STORAGE POLICY 


WARM_STORAGE POLICY 


XE 


COLD_STORAGE POLICY 


图 1-11 存储 策略 集合 
上 述 策略 中 有 一 个 策略 在 前 面 提 到 过 ， 就 是 LAZY_PERSIST。 此 策略 在 执行 的 时 候 会 先 将 数据 写 到 内 存 中 ， 然 后 再 持久 化 。 大 家 可 以 试 试 此 策略 ， 看 看 性 能 到 底 如 何 。 
1.2.5 “” 块 存储 策略 的 调用 


分 析 完 块 存储 策略 的 种 类 之 后 ， 我 们 看 看 HDFS 在 哪些 地 方 设置 了 这 些 策略 。 


首先 ， 我 们 要 知道 HDFS 的 默认 策略 是 哪 种 ， 默 认 策略 如 下 : 








@VisibleForTesting 

public static BlockStoragePolicySuite createDefaultSuite() { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
return new BlockStoragePolicySuite (hotId, policies); 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


public BlockStoragePolicySuite (byte defaultPolicyID, 
BlockStoragePolicy[] policies) { 
this.defaultPolicyID = defaultPolicyID; 
this.policies = policies; 
} 














可 以 看 出 ， 这 就 是 HOT 的 策略 。 也 就 是 说 ， 在 默认 情况 下 ，HDFSs 把 集群 中 的 数据 都 看 成 是 经 常 访问 的 数据 。 然 后 进一步 查看 getPolicy 的 方法 调用 ， 如 图 1-12 所 示 。 


vv © getPolicy(byte) : BlockStoragePolicy - org.apache.hadoop.hdfs.serverblockmanagement.BlockStoragePolic 
Pb 加 chooseExcessReplicates(Collection<DatanodeStoragelnfo>, Block, short, DatanodeDescriptor, Datanodk 

p © chooseTarget4AdditionalDatanode(String, int, Node, List<DatanodeStoragelnfo>, Set<Node>, long, byte, 

Pp © chooseTarget4NewBlock(String, int, Node, Set<Node>, long, List<String>, byte) : DatanodeStoragelnfol 


Pp 加 chooseTargets(BlockPlacementPolicy, BlockStoragePolicySuite, Set<Node>) : void - org.apache.hadoop 


pe computeContentSummary(ContentSummaryComputationContext) : ContentSummaryComputationConte; 
日 computeQuotaDeltaForUCBIlock(INodeFile) : QuotaCounts - org.apache.hadoop.hdfs.servernamenode.F 
> Bi computeQuotaDeltas(FSDirectory, INodeFile, INodeFile0) : QuotaCounts - org.apache.hadoop.hdfs.serve 
pd computeQuotaUsage(BlockStoragePolicySuite, byte, QuotaCounts, boolean, int) : QuotaCounts - org.ap' 
> @ getDefaultPolicy() : BlockStoragePolicy - org.apache.hadoop.hdfs.serverblockmanagement.BlockStorag 
> © getStoragePolicy(byte) : BlockStoragePolicy - org.apache.hadoop.hdfs.server.blockmanagement.BlockM 





图 1-12 ”getPolicy 方 法 调用 


我 们 以 方法 chooseTarget4NewBlock 为 例 ， 追 踪 一 下 上 游 的 调用 过 程 。 





public DatanodeStorageInfo[] chooseTarget4NewBlock(final String src, 
final int numOofReplicas, final Node client, 
final Set<Node> excludedNodes, 
final long blocksize, 


final List<String> favoredNodes, 
final byte storagePolicyID) throws IOException { 
List<DatanodeDescriptor> favoredDatanodeDescriptors = 
getDatanodeDescriptors (favoredNodes); 


final BlockStoragePolicy storagePolicy = storagePolicySuite.getPolicy (storagePolicyID); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 父 方法 中 获取 了 StoragePolicylD 策 略 ID， 往 上 追踪 ,来 到 了 FSNamesystem 的 get-NewBlockTargets 方 法 : 





DatanodeStorageInfo[] getNewBlockTargets (String src, long fileId, 
String clientName, ExtendedBlock previous, Set<Node> excludedNodes, 
List<String> favoredNodes, LocatedBlock[] onRetryBlock) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


replication = pendingFile.getFileReplication(); 
storagePolicyID = pendingFile.getStoragePolicyID(); 
} finally { 
readUnlock (); 
} 


if (clientNode == null) { 
clientNode = getClientNode (clientMachine); 


// 为 新 分 配 的 块 选择 目标 节点 
return getBlockManager () .chooseTarget4NewBlock ( 


src, replication, clientNode, excludedNodes, blockSize, favoredNodes, 


storagePolicyID); 





于 是 我 们 看 到 StoragePolicyID 是 从 INodeFile 中 获取 而 来 的 。 这 与 上 文中 目标 节点 请 求 的 过 程 类 似 ， 都 有 从 File 中 获取 策略 1d 的 动作 。 那 么 新 的 问题 又 来 了 ，INodeFile 中 的 storagePolicyID 从 何 而 来 


呢 ， 有 以 下 两 个 途径 : 


“ 通过 RPC 接 口 主 动 设置 。 


“ 没有 主动 设置 的 ID 会 继承 父 目 录 的 策略 ， 如 果 父 目录 还 是 没有 设置 策略 ， 则 会 设置 ID_UNSPECIFIED， 继 而 会 用 DEFAULT (默认 ) 存储 策略 进行 替代 ， 源 码 如 下 : 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


public byte getStoragePolicyID() { 
byte id = getLocalStoragePolicyID(); 
if (id == ID UNSPECIFIED) { 
return this.getParent () != null ? 
this.getParent () .getStoragePolicyID() : id; 
. 


return id; 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











综 上 ，HDFS 异 构 存储 总 的 过 程 调 用 见 图 1-13。 


MEMORY_STORAGE POLICY 


ALLSSD STORAGE POLICY 


ONESSD STORAGE POLICY SS 


HOT_STORAGE POLICY 





















BlockStoragePolicySuite 





WARM STORAGE _ POLICY 





COLD STORAGE _ POLICY 


1.2.6 ”HDFS 异 构 存储 策略 的 不 足 之 处 


三 | 




















getAllPolicies 


前 面 花 了 很 多 的 篇 幅 介绍 了 HDFS 各 种 异 构 存储 策略 的 特点 、 优 势 以 及 过 程 调用 ， 那 么 是 否 这 套 机 制 是 完美 无 缺 的 呢 ? 答案 当然 不 是 ， 下 


chooseTarget4WebHDFS 
xcessReplicates BlockPiacomentPolicy 


supply policyld 






















getPolicy setStoragePolicyID NameNodeRpcServer 






chooseTargets* 





INodeFile 





ID_UNSPECIFIED 













INodeDirectory 


DFSClient#getStoragePolicies 


图 1-13 ” 异 构 存储 策略 总 的 过 程 调用 

















回 








场景 就 不 适合 使 用 此 机 制 。 









































A 在 HDFS 上 创建 自己 的 存储 目录 /user/A， 不 设置 任何 的 存储 策略 ， 也 就 是 默认 都 存放 在 DISK 类 型 的 介质 上 。 忽 然 有 一 天 ， 他 发 现 自己 的 数据 已 经 不 怎么 使 用 了 ， 想 要 设置 其 存储 策略 为 COLD 类 


























型 ， 于 是 他 执行 了 相应 策略 的 setStoragePolicy 命 令 。 那 么 这 步 命令 操作 完了 是 否 意味 着 用 户 A 的 目的 达到 了 呢 ? 





© 














问题 就 出 在 变更 ， 目 前 HDFS 上 还 不 能 对 文件 目录 存储 策略 变更 做 出 自动 的 数据 迁移 。 这 里 需要 用 户 额外 执行 hdfs-mover 命 令 做 文件 目录 的 扫描 。 在 mover 命 令 扫描 的 过 程 中 ， 如 果 发 现 文 件 目录 的 实 


























际 存储 类 型 与 其 所 设置 的 storagePolicy 策 略 不 同 ， 将 会 进行 数据 块 的 迁移 ， 将 数据 迁移 到 相对 应 的 存储 介质 中 。 这 里 所 指 的 文件 目录 存储 策略 变更 有 以 下 两 类 情况 : 





“ 原先 未 设置 StoragePolicy， 后 来 进行 了 设置 。 


“ 原先 设置 了 A 策略 ， 后 来 又 设置 了 B 策 略 。 





针对 这 个 问题 ， 社 区 目前 已 经 有 相关 的 JIRA 在 解决 这 个 问题 ，HDFS-10285 (Storage Policy Satisfier in Namenode) ， 在 这 个 镍 RA 里 已 经 包含 了 详细 的 设计 文档 ， 如 果 这 个 问题 被 解决 了 ， 将 会 是 一 








个 很 实用 的 功能 。 











1.2.7 ”HDFS 存 储 策略 的 使 用 














本 节 最 后 介绍 几 个 关于 存储 策略 的 使 用 命令 ， 帮 助 大 家 真正 学 会 运 














这 个 强大 的 特性 。 输 入 hdfs storagepolicies-help， 你 会 得 到 以 下 三 大 操作 命令 : 





$ hdfs storagepolicies -help 


[-listPolicies] // 列 出 目前 现 有 的 存储 策略 
[-setStoragePolicy -path <path> -policy <policy>] // 对 目标 文件 /目录 设置 存储 策略 





以 下 为 此 命令 的 必 填 参数 : 





<path> ”需要 设置 存储 策略 的 文件 /目录 路 径 
<policy> 对 目标 设置 的 存储 策略 


[-getStoragePolicy -path <path>] // 获取 给 定 路 径 的 存储 策略 


以 下 为 此 命令 的 必 填 参数 : 


<path> 需要 获取 存储 策略 的 输入 路 径 
































在 以 上 三 大 操作 命令 中 ，setStoragePolicy 为 设置 命令 ，listPolicies 和 getStoragePolicy 都 是 获取 命令 。 最 简单 的 使 用 方法 是 








先 划 分 好 冷 热 数据 的 存储 目录 ， 设 置 好 对 应 的 存储 策略 ， 后 续 使 用 相应 的 
























































途 在 于 它 会 扫描 HDFS 上 的 文件 ， 判 断 文件 是 否 满足 : 








程序 在 对 应 分 类 目录 下 写 数据 ， 自 动 继承 父 目录 的 存储 策略 。 在 较 新 版 的 Hadoop 发 布 版 本 中 增加 了 数据 迁移 工具 。 此 工具 的 重要 





内 部 设置 的 存储 策 




















略 ; 如 果 不 满 足 ， 就 会 重新 迁移 数据 到 目标 存储 类 型 节点 上 。 使 用 方式 如 下 : 














$ hdfs mover -help 
Usage: hdfs mover [-p <files/dirs> | -f <local file>] // hdfs mover 数 据 迁 移 命令 
-p <files/dirs> // 需要 被 迁移 的 HDFS 文 件 / 目 录 的 路 径 
-£f <local file> // 需要 被 迁移 的 HDFS 文 件 /目录 对 应 的 本 地 文件 系统 路 径 





其 中 一 个 参数 针对 HDFS 的 文件 目录 ， 另 一 个 参数 针对 本 地 的 文件 。 








HDFS 异 构 存储 功能 的 出 现 绝对 是 解决 冷 热 数据 存储 问题 的 一 把 利器 ， 希 望 通过 本 节 内 容 的 阐述 能 给 大 家 带 来 全 新 的 认识 。 


1.3 小 结 


本 章 介绍 了 HDFS 的 内 存 存储 和 异 构 存储 ， 前 者 是 后 者 的 一 种 存储 方式 。HDFS 的 内 存 存储 方式 的 难点 在 于 它 如 何 对 数据 进行 持久 化 ， 其 中 还 涉及 LRU 算 法 。 而 HDFS 异 构 存 储 的 





的 整体 实现 原理 ， 通 过 对 DataNode 上 的 数据 目录 以 及 HDFS 上 的 目标 路 径 打 标签 的 方式 来 进行 数据 的 存储 选择 。 


第 2 章 ”HDFS 的 数据 管理 与 策略 选择 








本 章 我 们 要 学 习 HDFS 的 数据 管理 ，HDFS 有 独特 的 数据 管理 方式 和 策略 选择 。 本 章 首 先 介绍 HDF3 缓 存 方面 的 管理 ， 包 括 缓存 块 与 DataNode 数 









































第 二 介绍 HDFS 的 快照 管理 ， 快 照 在 很 多 应 用 的 场景 下 可 以 用 来 进行 数据 的 故障 恢复 ， 在 HDFS 中 ， 它 有 相似 的 作用 。 第 三 介绍 经 典 | 
的 Sasl 认 证 与 Blocktoken 验 证 机 制 以 及 二 者 实现 的 差别 。 最 后 介绍 DataNode 内 部 的 三 大 “数据 保镖 ”服务 : VolumeScanner、D 

















2.1 ”HDFS 缓 存 与 缓存 块 





























HDFSs 的 缓存 与 我 们 平常 所 说 的 缓存 (cache) 在 作用 上 是 一 致 的 ， 主 要 是 为 了 减少 重复 的 数据 请 求 过 程 。 但 是 在 具体 实现 上 ，， 





























是 缓存 块 (cache block) 的 概念 。HDFS 的 缓存 块 由 普通 的 文件 块 转换 而 来 ， 同 样 也 可 以 转换 回去 。HDFS 缓 存 的 出 现 可 以 大 大 提高 用 户 读 取 文 件 的 速度 ， 因 








需 进行 读 取 磁 盘 的 操作 。 在 本 节 中 ， 我 们 主要 介绍 缓存 块 的 缓存 原理 、 缓 存 块 的 周期 状态 以 及 缓存 块 不 同 状态 之 间 的 转换 等 内 容 。 

















点 在 于 理解 此 套 机 制 


居 之 间 的 交互 ，HDFS 整 体 的 中 心 缓存 机 制 的 实现 原理 。 


的 三 副本 策略 ， 及 其 在 HDFs 中 如 何 做 到 数据 的 高 可 用 性 。 第 四 介绍 HDFS 


irectoryScanner 以 及 DiskChecker。 











我 们 平常 所 用 的 缓存 可 能 只 由 一 个 简单 的 缓冲 数组 构成 ， 而 HDFS 用 的 
为 它 是 缓存 在 DataNode 内 存 中 的 ， 此 过 程 无 
































笔者 在 学 习 HDFS 缓 存 方面 的 原理 过 程 中 ， 感 觉 到 其 中 的 逻辑 有 点 绕 ， 直 接 分 析 不 见得 会 起 到 很 好 的 效果 ， 所 以 这 里 采取 疑问 点 的 形式 来 做 一 个 引导 。 在 列 出 下 面 几 个 疑问 点 之 前 ， 需 要 了 解 一 些 相关 名 
称 的 定义 : 在 HDFS 中 缓存 的 对 象 是 数据 块 ， 需 要 缓存 的 目标 数据 块 称 为 CacheBlock， 不 需要 缓存 的 数据 块 称 为 UnCacheBlock。 以 下 是 本 节 所 要 答复 的 疑问 点 : 
































“ 物理 层面 缓存 块 是 怎样 的 ? 

“ 缓存 块 的 生命 周期 状态 有 哪 几 种 ? 

“ 哪些 情况 会 触发 缓存 块 、 取 消 缓存 块 的 操作 ? 
.CacheBlock、UnCacheBlock 缓 存 块 如 何 确定 ? 
“ 系统 所 持 有 的 缓存 块 列 表 如 何 更 新 ? 

“ 缓存 块 如 何 被 使 用 ? 


下 面 将 详细 讲述 这 些 内 容 。 





2.1.1 ”HDFS 物 理 层面 缓存 块 

















物理 层面 缓存 块 这 个 词 在 HDFS 源 码 中 的 解释 如 下 : “利用 mmap、mlock 这 样 的 系统 调用 将 块 数据 锁 入 内 存 ， 以 此 达到 在 DataNode 上 缓存 数 拉 
， 它 是 一 个 内 存 映射 调用 。mmap 主 要 作用 是 将 一 个 文件 或 者 













































































入 内 存 。 没 接触 过 底层 操作 系统 知识 的 人 可 能 不 是 很 清楚 mmap、mlock 调 用 是 怎么 一 回 事 ， 下 面 简单 介绍 一 下 。mmap 系 统 调 
射 进 内 存 。 将 文件 或 其 他 对 象 映 射 进 内 存在 代码 中 的 体现 如 下 所 示 : 









































居 的 效果 。” 大 意 为 利用 mmap、mlock 系 统 调用 将 块 锁 











其 他 对 象 映 




















// 加 载 并 映射 块 到 内 存 ， 然 后 检验 其 checksum 
Public static MappableBlock load(long length, 
FileInputStream blockIn, FileInputStream metaIny 
String blockFileName) throws IOException { 
MappableBlock mappableBlock = null; 
MappedByteBuffer mmap = null; 
FileChannel blockChannel = null; 
try { 


// 获取 块 数据 的 FileChanne1 对 象 
blockChannel = blockIn.getChannel () 7 
if (blockChannel == null) { 
throw new IOException ("Block InputStream has no FileChannel."); 


} 
// 这 里 开始 进行 内 存 的 映射 操作 
mmap = blockChannel .map (MapMode.READ ONLY, 0, length); 
NativeIO.POSIX.getCacheManipulator () .mlock (blockFileName, mmap, length); 
verifyChecksum(length, metalIn, blockChannel, blockFileName); 
mappableBlock = new MappableBlock (mmap, length); 
} finally { 
IOUtils.closeQuietly (blockChannel); 
if (mappableBlock == null) { 
if (mmap != null) { 
// 解除 地 址 区 域 的 对 象 映射 
NativeIO.POSIX.munmap (mmap); 
} 
} 
} 
return mappableBlock; 
} 





在 上 面 的 代码 中 ， 将 blockChannel 对 象 本质 对 象 是 FileChannel) 映射 到 了 内 存 中 。 当 然 这 是 最 底层 执行 的 操作 了 ， 在 HDFS 中 的 上 层 调 


2.1.2 ”缓存 块 的 生命 周期 状态 

















是 如 何 的 呢 ， 这 才 是 我 们 所 要 真正 关心 的 ， 下 面 继续 讲 。 


缓存 块 的 生命 周期 不 仅仅 只 有 Cached (已 缓存 ) 和 UnCached (未 缓存 ) 两 种 。 在 FSDatasetCache 类 中 ， 有 了 明确 的 定义 : 





Private enum State { 
// 缓存 块 缓存 中 状态 
CACHING, 


// 缓存 块 取消 状态 
CACHING CANCELLED, 


// 缓存 块 已 缓存 状态 
CACHED, 


// 缓存 块 取消 缓存 状态 
UNCACHING; 


// 块 是 否 已 缓存 判断 方法 
Public boolean shouldAdvertise() { 
return (this == CACHED); 
} 
} 





上 面 的 Cache 状 态 信 息 总 共 分 为 四 类 : 
CACHING 表示 块 正在 被 缓存 。 
“ CACHING_CANCELLED 正 在 被 缓存 的 块 已 处 于 被 取消 的 状态 。 
“CACHED 表 明 数 据 块 已 被 缓存 。 
“UNCACHING 表 明 缓 存 块 正 处 于 取消 缓存 的 状态 。 
在 HDFS 的 缓存 过 程 中 有 这 四 类 缓存 状态 ， 并 可 以 切换 。 


这 个 状态 信息 保存 在 FsDatasetCache 的 Value 内 部 类 中 : 





// 缓存 状态 信息 
private static final class Value { 
// 缓存 状态 对 象 
final State state; 
// 缓存 块 对 象 
final MappableBlock mappableBlock; 


Value (MappableBlock mappableBlock, State state) { 
this.mappableBlock = mappableBlock; 
this.state = state; 
’ 
} 








[ 


实际 存储 的 Value 对 象 与 块 1d 对 象 构成 了 缓存 映射 














private final HashMap<ExtendedBlockId, Value> mappableBlockMap = 
new HashMap<ExtendedBlockId, Value>(); 




















可 能 有 人 会 问 为 什么 这 里 不 直接 用 64 位 的 块 Id 直接 当 key， 而 是 用 ExtendedBlockld 对 象 ， 这 是 | 












































ExtendedBlockld、Value 键 值 对 的 存储 与 清除 发 生 在 cacheBlock 和 uncacheBlock 方 法 内 : 


为 BlockPool 的 存在 。 现 在 的 HDFS 是 支持 多 命名 空间 的 ， 块 Id 只 在 同一 个 BlockPool| 下 唯一 。 





synchronized void cacheBlock (long blockId, String bpid, 
String blockFileName, long length, long genstamp, 
Executor volumeExecutor) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


mappableBlockMap.put (key, new Value (null, State.CACHING)); 
VolLumeExecutor .execute ( 
new CachingTask (key, blockFileName, length, genstamp)); 
LOG.debug ("Initiating caching for Block with id {}, pool {}", blockId, 
bpid); 





然后 将 块 文件 信息 传 入 CachingTask 中 异步 执行 。 同 理 uncacheBlock 方 法 也 放 在 了 异步 线程 中 执行 : 


synchronized void uncacheBlock (String bpid, long blockId) { 
ExtendedBlockId key = new ExtendedBlockId (blockId, bpid); 
// 获取 当前 缓存 块 对 象 
Value prevValue = mappableBlockMap.get (key); 
boolean deferred = false; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 进行 块 对 象 缓存 状态 的 判断 
Switch (prevValue.state) { 
Case CACHING: 
LOG.debug ("Cancelling caching for block with id {}, pool {}.", blockId, 
bpid); 
mappableBlockMap .put (key, 
new Value (prevValue.mappableBlock, State.CACHING CANCELLED)); 
break; 


Case CACHED: 
// 如 果 是 已 缓存 状态 ， 则 将 进行 取消 缓存 操作 
mappableBlockMap .put (key, 
new Value (prevValue.mappableBlock, State.UNCACHING)); 
if (deferred) { 
LOG.debug ("{} is anchored, and can't be uncached now. Scheduling it "+ 
"for uncaching in {} ", 
key, DurationFormatUti1s .formatDurationHMS (revocationPollingMs)); 
deferreqUncachingExecutor.schedule( 
new UncachingTask (key, revocationMs), 
revocationPollingMs, TimeUnit .MILLISECONDS); 
} else { 
LOG.debug ("{} has been scheduled for immediate uncaching.", key); 
uncachingExecutor.execute (new UncachingTask (key, 0)); 
} 


break; 
default: 
LOG. debug(" "Block with id {}, pool ,和 does not need to be uncached, " 
+ "because it is in state {}.", blockId, bpid, prevValue.state); 
numBlocksFailedToUncache.incrementAndGet (); 
break; 


} 
} 





2.1.3 ”CacheBlock、UnCacheBlock 场 景 触发 


什么 下 情况 会 触发 缓存 块 的 行为 呢 ? 同样 我 们 要 将 此 情形 分 为 两 类 : 一 类 是 CacheBlock， 另 外 一 类 是 UnCacheBlock。 


1.CacheBlock 动 作 











在 Eclipse 编译 器 中 通过 open call 的 方式 可 以 追踪 出 它 的 上 层 方法 调用 ， 如 图 2-1 所 示 。 











了 如 cacheBlock(long, String, String, long, long, Executor) : void - org.apache.hadoop.hdfs.s' 
y 国 cacheBlock(String, long) : void - org.apache.hadoop.hdfs.server.datanode.fsdataset.i 
了 © cache(String, long[]) : void - org.apache.hadoop.hdfs.server.datanode.fsdataset.ir 


国 processCommandFromActive(DatanodeCommand, BPServiceActor) : boolean - 
外 processCommandFromActor(DatanodeCommand, BPServiceActor) : boolea 
> a processCommand(DatanodeCommand[) : boolean - org.apache.hadoop,. 





图 2-1 CacheBlock 调 用 











最 下 层 的 方法 表明 了 此 方法 最 终 来 自 于 NameNode 心 跳 处 理 的 方法 ， 进 入 此 方法 进行 查阅 : 








private boolean processCommandFromActive (DatanodeCommand cmd, 
BPServiceActor actor) throws IOException { 

final BlockCommand bcmd = 

cmd instanceof BlockCommand? (BlockCommand)cmd: null; 

final BlockIdCommand blockIdcmd = 

cmd instanceof BlockIdCommand ? (BlockIdCommand)cmd: null; 


Switch (cmd.getAction()) { 


// DataNode 获 取 到 心跳 返回 的 缓存 命令 
case DatanodeProtocol.DNRA_CACHE : 
LOG.info (“DatanodeCommand action: DNA CACHE for \ + 
blockIdcmd.getBlockPoolId() + of [V+ 
blockIdArrayToString (blockIdCmd.getBlockIds()) + “]”); 
// 进行 缓存 块 的 动作 ， 目 标 缓存 块 列 表 也 是 从 心跳 回复 中 获得 
dn.getFSDataset () .cache (blockIdCmd .getBlockPoolId(), ，blockIdcmd.getBlockIds ()); 
break; 


default: 
LOG.warn (“Unknown DatanodeCommand action: “ + cmd.getAction()); 


return true; 


bE 





2.UnCacheBlock 动 作 











取消 缓存 块 的 动作 是 否 也 来 自 NameNode 的 回复 命令 呢 ? 答案 其 实 不 仅 限于 此 。 调 用 关系 图 如 图 2-2 所 示 。 


YY 如 uncacheBlock(String, long) : void - org.apache.hadoop.hdfs.serverdatanode.fsdataset.impl.FsDatasetC 
> yappend(String, FinalizedReplica, long, long) : ReplicaBeingWritten - org.apache.hadoop.hdfs.server. 


> ©® invalidate(String, Block[]) : void - org.apache.hadoop.hdfs.serverdatanode.fsdataset.impl.FsDataset 
> ©® invalidate(String, Replicalnfo) : void - org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDat 
> ©® uncache(String, long([]) : void - org.apache.hadoop.hdfs.serverdatanode.fsdataset.impl.FsDatasetlm 





图 2-2 UnCache 调 用 
可 以 看 到 ， 这 里 总 共有 三 类 调用 情况 : 
当 块 执行 4ppend 写 操作 的 时 候 。 
“ 当 把 块 处 理 为 无 效 块 的 时 候 。 


" 上 层 NameNode 发 送 uncache 回 复命 令 的 时 候 。 





最 后 一 种 跟 之 前 CacheBlock 提 到 的 情况 一 样 ， 都 是 由 NameNode 的 回复 命令 所 触发 的 。 前 面 两 类 情况 导致 取消 缓存 动作 的 理由 很 好 理解 ， 原 因 如 下 : 


“ 因为 对 块 继 续 执 行 了 写 动作 ， 数 据 必然 发 生 改 变 ， 原 有 的 缓存 块 需要 重新 更 新 。 


: 当 把 块 处 理 为 无 效 块 的 时 候 ， 接 着 会 被 NameNode 从 系统 中 清除 ， 缓 存 块 自然 而 言 就 没有 存在 的 必要 了 。 


2.1.4 ” CacheBlock、UnCacheBlock 缓 存 块 的 确定 


目标 缓存 块 的 确定 问题 本 质 上 等 同 于 NameNode 回 复命 令 中 CacheBlock、UnCacheBlock 的 块 1d 的 确定 问题 ， 就 是 如 下 代码 中 的 BlockPoolld 和 Blocklds: 








dn.getFSDataset () .cache (blockIdCmd.getB1lockPoolId()，blockIdcmd.getBlockIds ()); 











复命 令 构造 的 过 程 。 这 里 进入 到 DatanodeManager 的 handleHeartbeat 命 令 处 理 方法 : 





回 








blockldCmd 是 NameNode 心 跳 处 理 的 回复 命令 ， 所 以 必然 存在 | 








if (shouldSendCachingCommands && 
( (nowMs - nodeinfo.getLastCachingDirectiveSentTimeMs () ) >= 
timeBetweenResendingCachingDirectivesMs)) { 
// 构造 需要 缓存 的 块 命令 
DatanodeCommand pendingCacheCommand = 
getCacheCommand (nodeinfo.getPendingCached(), nodeinfo, 
DatanodeProtocol .DNA CACHE, blockPoolId); 
if (pendingCacheCommand != null) { 
cmds.add (pendingCacheCommand); 
sendingCachingCommands = true; 


} 
// 构造 需要 取消 缓存 的 块 命 
DatanodeCommand pendingUncacheCommand = 
getCacheCommand (nodeinfo.getPendingUncached(), nodeinfo, 
DatanodeProtocol .DNA UNCACHE, blockPoolId); 

if (pendingUncacheCommand T= null) { 

cmds.add (pendingUncacheCommand); 

sendingCachingCommands = true; 


if (sendingCachingCommands) { 
nodeinfo.setLastCachingDirectiveSentTimeMs (nowMs); 
} 
} 





从 这 里 可 以 看 出 ，CacheBlock 和 UnCacheBlock 来 源 于 nodelnfo 中 的 pendingCache 和 pendingUncache 对 象 信息 ， 实 质 上 获取 的 变量 如 下 : 








// DataNode 上 已 缓存 的 缓存 块 列表 
Private final CachedBlocksList cached = 
new CachedBlocksList (this, CachedBlocksList.Type.CACHED); 





// DataNode 上 待 取消 缓存 的 缓存 块 列表 
private final CachedBlocksList PendingUncached = 
new CachedBlocksList (this, CachedBlocksList.Type.PENDING UNCACHED); 





描 整 个 HDFS 文 件 系 统 ， 根 据 情况 调度 块 进行 缓存 。” 




















只 要 能 找到 CachedBlockList 的 直接 操作 方 ， 就 能 明白 缓存 块 、 待 取消 缓存 块 是 如 何 确定 的 。 通 过 进一步 地 上 层 调用 ， 最 后 发 现 真正 的 操作 主 类 CacheReplicationMonitor， 这 个 类 的 用 途 如 下 : “ 扫 






































在 这 里 笔者 做 部 分 补充 解释 ，CacheReplicationMonitor 自 身 持 有 一 个 系统 中 的 标准 缓存 块 列表 ， 然 后 通过 自身 内 部 的 缓存 规则 ， 进 行 缓存 块 的 添加 和 移 除 ， 然 后 对 应 更 新 到 之 前 提 到 过 的 














pendingCache 和 pendingUncache 列 表 中 ， 随 后 这 些 信息 会 被 NameNode 拿 来 放 入 回复 命令 中 。 这 里 会 有 2 个 疑问 点 : 


“CacheReplicationMonitor 内 部 维护 的 系统 标准 缓存 块 从 哪里 来 ? 
“ CacheReplicationMonitor 内 部 缓存 规则 、 策 略 是 什么 ， 什 么 情况 下 块 应 该 被 缓存 ， 什 么 情况 下 又 可 以 取消 缓存 ? 
第 一 个 问题 会 在 后 面 的 小 节 中 提 到 ， 这 里 主要 看 第 二 条 ， 答 案 在 rescanCached-BlockMap 的 方法 中 。 此 方法 代码 处 理 逻 辑 比较 复杂 ， 从 方法 注释 中 的 解释 ， 我 们 可 以 归纳 出 下 面 两 个 基本 规则 : 
“ 任何 少 于 标准 副本 块 个 数 的 副本 应 该 被 缓存 到 新 的 节点 上 。 
“ 过 量 副本 数 的 缓存 块 应 该 从 节点 上 进行 移 除 。 


其 实 仔细 一 想 ， 这 个 策略 还 是 很 巧妙 的 ， 尽 量 多 缓存 一 些 副本 数 不 足 的 副本 (缓存 相当 于 充当 了 一 块 副本 ) ， 移 除 掉 副 本 数 过 多 的 多 余 缓 存 。 





2.1.5 “系统 持 有 的 缓存 块 列表 如 何 更 新 


























上 文中 提 到 过 CacheReplicationMonitor 对 象 持 有 的 系统 缓存 块 列 表 如 何 被 更 新 的 问题 ， 这 个 列表 是 用 来 发 送 pendingCache、pengdUncache 信 息 的 基础 。 因 为 缓存 块 列表 是 系统 全 局 持 有 的 ， 会 存 
反馈 上 报 的 过 程 ， 相 关 代 码 位 于 心跳 处 理 代 码 的 附近 : 











http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
List<DatanodeCommand> cmds = blockReport (); 

processCommand (cmds == null ? null : cmds.toArray (new DatanodeCommand [cmds.size()])); 

// 缓存 块 的 上 报 

DatanodeCommand cmd = cacheReport () 7 

processCommand (new DatanodeCommand[]{ cmd }); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











继续 调用 到 下 面 这 行 操作 : 














// 获取 到 DataNode 上 的 缓存 块 id 列 表 
List<Long> blockIds = dn.getFSDataset () .getCacheReport (bpid); 





























最 后 又 重新 调用 到 了 FSDatasetCache 中 的 getCacheBlocks 方 法 。 至 此 我 们 可 以 发 现 ， 这 里 形成 了 一 个 闭环 操作 ， 最 后 的 缓存 操作 执行 者 同样 也 是 缓存 块 情况 的 反馈 者 。CacheReplicationMonitor 属 





























于 CacheManager 对 象 的 内 部 变量 ， 会 从 中 拿 到 缓存 块 的 最 新 信息 。 同 时 这 里 需要 注意 一 点 ，CacheManager 自 身 同 样 可 以 主动 添加 新 的 目标 缓存 块 ， 对 应 的 命令 是 hdfs cacheadmin。HDFS 缓 存 块 命令 
的 相关 内 容 在 后 面 的 内 容 中 会 提 及 到 。 





2.1.6 ”缓存 块 的 使 用 
































这 时 候 重 新 回头 看 缓存 块 的 使 用 ， 问 题 就 显得 比较 简单 了 。 缓 存 块 在 ShortCircuit (短路 读 ) 的 操作 中 被 用 到 (参见 第 6 章 6.2.5 节 ) ， 代 码 如 下 : 











public void requestShortCircuitFds (final ExtendedBlock blk, 
final Token<BlockTokenIdentifier> token, 
SlotId slotId, int maxVersion, boolean supportsReceiptVerification) 
throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
if (slotId != null) { 


boolean isCached = datanode.data. 
isCached (blk.getBlockPoolId(), blk.getBlockId()); 
Gatanode. shortCircuitRegistry.registerSlot( 
ExtendedBlockId. fromExtendedBlock (blk), slotId, isCached); 
registeredSslotId = slotId; 
} 
fis = datanode.requestShortCircuitFdsForRead (blk, token, maxVersion); 
Preconditions.checkstate (fis != null); 
bld.setStatus (SUCCESS); 
bld.setShortCircuitAccessVersion (DataNode.CURRENT BLOCK FORMAT VERSION); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















最 后 给 出 完整 调用 流程 ， 如 图 2-3 所 示 。 我 们 可 以 明显 看 到 中 间 的 一 个 闭环 。 
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图 2-3 ”缓存 机 制 流程 
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2.1.7 ”HDFS 缓 存 相关 配置 


讲述 完 关 于 HDFS 缓 存 的 原理 和 内 容 之 后 ， 接 下 来 介绍 管控 此 功能 的 配置 项 ， 如 下 所 示 : 





<property> 
<name>dfs.datanode .max.1locked.memory</name> 
<value>0</value> 
<description> 
DataNogde 用 来 缓存 块 的 最 大 内 存 空间 大 小 ， 单 位 用 字 节 表示 。 系 统 变量 RLIMIT_ MEMLOCK 至 少 需要 设置 
得 比 此 配置 值 要 大 ， 否 则 DataNode 会 出 现 启动 失败 的 现象 。 在 默认 的 情况 下 ， 皮 配置 值 为 0， 表 明 默 认 关 
闭 内 存 缓存 的 功能 。 
</description> 
</property> 

















这 个 配置 项 的 名 称 与 实际 所 使 用 的 功能 情况 不 太一 致 ， 有 点 歧义 的 感觉 ， 可 能 叫 dfs.datanode.max.cache.memory 比 较 好 理解 一 些 。 这 个 配置 项 控制 的 是 下 面 这 个 变量 ， 在 FSDatasetCache 构 造 函 数 
中 首先 会 拿 到 此 属性 值 : 














this .maxBytes = dataset.datanode.getDnConf () .getMaxLockedMemory () 7 





然后 在 usedBytes 对 象 的 使 用 上 做 限制 : 





long reserve(long count) { 
count = rounder.round (count); 
while (true) { 
long cur = usedBytes .get (); 
long next = cur + count; 
// 如 果 当 前 内 存 使 用 量 已 经 超过 最 大 允许 使 用 值 ， 则 返回 -1 
if (next > maxBytes) { 
return -1; 


} 
if (usedBytes.compareAndSet (cur, next)) { 
return next; 





“ 第 一 点 ， 此 配置 项 会 受 系统 最 大 可 使 用 内 存 大 小 (RLIMIT_MEMLOCK) 的 影响 ， 造 成 启动 DataNode 失 败 的 现象 ， 会 有 如 下 的 错误 输出 : 





Cannot start datanode because the configured max locked memory size.. is more than the datanode’s available RLIMIT MEMLOCK ulimit. 





上 面 的 记录 表明 操作 系统 不 能 提供 相应 大 小 的 内 存 ， 可 以 通过 tlimit -1<value> 命 令 对 此 进行 调整 。 一 般 而 言 ， 这 个 值 是 在 /etc/security/limits.conf 文 件 中 配置 的 。 


“ 第 二 点 ， 此 配置 项 并 不 是 HDFS 缓 存 机 制 所 独 有 的 ， 它 与 HDFS 的 LAZY_PERSIST 策 略 会 共享 dfs.datanode.max.locked.memory 配 置 。 换 句 话 说， 如 果 用 于 LAZY_PERSIST 的 存储 数据 块 多 了 ， 那 么 HDFS 
缓存 所 能 使 用 的 空间 自然 就 会 变 少 。 


最 后 附 上 几 个 与 HDFS 缓 存 相关 的 配置 参数 : 
“ dfs.datanode.fsdatasetcache.max.threads.per.volume: 用 于 缓存 块 数据 的 最 大 线程 数 ， 这 个 线程 数 是 针对 每 个 存储 目录 而 言 ， 默 认 值 为 4。 


“ dfs.cacherepott.intervalMsec: 缓存 块 上 报 间隔 ， 默 认 10 秒 。 


HDFS 缓 存 功 能 上 默认 是 关闭 的 ， 大 家 可 以 通过 配置 dfs.datanode.max.locked.memory 的 值 来 开启 此 功能 ， 对 于 文件 数据 的 读 性 能 将 会 带 来 不 小 的 提升 。 


2.2 ”HDFS 中 心 缓存 管理 








HDFS 中 心 缓存 管理 偏重 于 “中 心 管理 ”4 个 字 ，“ 缓 存 ”是 其 中 管理 的 对 象 。HDFS 中 心 缓存 管理 机 制 主要 依赖 于 中 心 缓存 管理 器 (CacheManager) 以 及 缓存 块 监控 服 











务 (CacheReplicationMonitor) 。 通 过 二 者 的 协作 ， 来 控制 集群 缓存 块 的 状态 。 在 本 节 中 ， 我 们 将 从 HDFS 缓 存 的 适 


2.2.1 ”HDFS 缓 存 适用 场景 






































首先 ， 我 们 先 要 了 解 HDFS 缓 存 所 适用 的 场景 ， 换 句 话说 ， 它 能 解决 哪些 具体 的 问题 。 















































场景 、 中 心 缓存 管理 的 原理 过 程 以 及 HDFS 缓 存 的 命令 使 用 三 个 方面 展开 讲述 。 











: 公共 资源 文件 。 这 些 文件 可 以 是 一 些 存 放 于 HDFS 中 的 依赖 资源 jar 包 ， 或 是 一 些 算法 学 习 依赖 


























的 .so 文件 等 。 像 这 类 数据 文件 ， 放 在 HDFS 上 的 好 处 是 我 们 可 以 在 HDFS 上 全 局 共享 ， 
这 种 场景 更 好 的 做 法 是 把 它 做 成 分 布 式 缓存 ， 否 则 在 程序 中 将 会 发 送 大 量 的 请 求 到 NameNode 中 去 获取 这 些 资源 文件 的 内 容 。 而 且 这 种 请 求 量 是 非常 恐怖 的 ， 不 是 说 请 求 一 次 就 够 了 ， 而 是 使 用 一 次 就 请 求 











一 次 。 


不 




















依赖 本 地 机 器 的 资源 文件 。 此 外 这 种 做 法 易于 管理 ， 如 果 想 要 进行 资源 包 的 升级 ， 可 以 直接 更 新 到 HDFS 上 。 但 是 






































第 二 种 场景 : 短期 临时 的 热点 数据 文件 。 比 如 集群 中 每 天 运行 统计 的 报表 数据 ， 需 要 读 取 前 一 天 的 或 是 最 近 一 周 的 数据 做 离线 分 析 。 但 是 超出 这 个 期 限 内 的 数据 基本 就 很 少 再 用 到 了 ， 就 可 以 视 为 冷 数 


据 了 。 那 么 这 个 时 候 我 们 就 可 以 把 符合 这 个 时 间 段 的 数据 做 缓存 处 理 ， 如 果 数 据 过 期 了 ， 就 直接 从 缓存 中 清除 。 














以 上 两 种 情况 ， 都 是 HDFS 缓 存 非常 适用 的 场景 。 














2.2.2 ”HDFS 缓 存 的 结构 设计 














在 HDFS 中 ， 最 终 缓存 的 本 质 是 数据 文件 。 但 是 在 逻辑 上 ， 引 入 了 下 面 几 个 概念 。 


1.CacheDirective 











CacheDirective 是 缓存 的 基本 单元 ， 但 是 这 里 CacheDirective 不 一 定 针 对 的 是 一 个 目录 ， 也 可 以 是 一 个 文件 。 

















其 中 主要 包括 以 下 一 些 变量 : 














public final class CacheDirective implements IntrusiveCollection.Element { 


// 唯一 标识 Id 

private final long id; 

// 目标 缓存 路 径 

private final String path; 

7 光路 径 的 文件 二 本 雪 

private final short replication; 
// 所 属 缓存 池 

Private CachePool pool; 

// 过 期 时 间 

private final long expiryTime; 
// 相关 统计 指标 

Private long bytesNeeded; 
Private long bytesCached; 
Private long filesNeeded; 
Private long filesCached; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 这 里 ， 我 们 看 到 了 一 个 新 的 概念 : 缓存 池 (CachePool) ， 在 此 可 以 得 出 下 





CacheDirective 属 于 对 应 的 缓存 池 。 








2.CachePool 


下 面 是 CachePool| 概 念 的 定义 

















对 
3 





public final class CachePool { 

// 缓存 池 名 称 

@Nonnull 
private final String poolName; 
// 所 属 用 户 名 

@Nonnull 

private String ownerName; 

// 所 属 组 名 

@Nonnull 

private String groupName; 

7 缓存 池 权 限 ， 分 为 读 (READ) 、 写 (WRITE) 、 可 执行 (EXECUTE) 
@Nonnull 

private FsPermission mode; 

7 缓存 池 最 大 允许 的 缓存 字 节 数 
private long limit; 

// 过 期 时 间 

Private long maxRelativeExpiryMs; 
7 变量 统计 相关 值 

Private long bytesNeeded; 
Private long bytesCached; 
Private long filesNeeded; 
private long filesCached; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 


og 蜂 丰 对象 表 
@Nonnull 


private final DirectiveList directiveList = new DirectiveList (this); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








我 们 可 以 看 到 ， 在 缓存 池 中 确实 维护 了 一 个 缓存 单元 列表 。 同 时 这 些 缓存 池 被 CacheManager 所 掌管 ，CacheManager 在 这 里 就 好 比 一 个 总 管理 者 的 角色 。 在 CacheManager 中 还 运行 着 一 个 很 重要 





的 服务 : 缓存 副本 监控 器 (CacheReplicationMonitor) 。 
总 结构 关系 如 图 2-4 所 示 。 














这 个 监控 程序 会 周期 性 地 扫描 当前 最 新 的 缓存 路 径 ， 并 分 发 缓存 块 到 对 应 的 DataNode 节 点 上 。 这 个 线程 服务 在 后 面 还 会 























体 提 到 。HDFS 缓 存 的 
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路 径 类 型 


Directory File 


图 2-4 HDFS 缓 存 总 结构 关系 


2.2.3 HDFS 缓 存 管理 机 制 分 析 


在 上 一 节 的 内 容 中 我 们 偏重 介绍 HDFS 缓 存 块 的 内 容 ， 而 在 本 节 我 们 会 偏向 讲述 缓存 管理 方面 的 内 容 ， 主 要 为 以 下 两 方面 的 内 容 : 





“ CacheAdmin CLI 命 令 在 CacheManager 的 实现 。 
“ CacheManaget 的 CacheReplicationMonitor 如 何 将 目标 缓存 文件 缓存 到 DataNode 中 。 


下 面 先 来 看 第 一 点 涉及 的 内 容 。 


1.CacheAdmin CLI 命 令 在 CacheManager 的 实现 





























CacheAdmin 是 HDFS 中 缓存 块 的 管理 命令 。 在 CacheAdmin 中 的 每 个 操作 命令 ， 最 后 通过 RPC 调 用 都 会 对 应 到 CacheManager 中 的 一 个 具体 操作 方法 。 在 此 过 程 中 要 解决 下 面 几 个 主要 疑问 点 : 








“ CacheManager 维 护 了 怎样 的 CachePool、CacheDirective 关 系 ? 
' 添加 新 的 CacheDirective、CachePool 有 哪些 特殊 的 细节 ? 


对 于 第 一 个 问题 ，CacheManager 确 实 维 护 了 CachePool、CacheDirective 的 多 种 映射 关系 ， 如 下 所 示 : 





public final class CacheManager { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// CacheDirective id 对 CacheDirective 的 映射 关系 
private final TreeMap<Long, CacheDirective> directivesById = 
new TreeMap<Long, CacheDirective>(); 
// 缓存 路 径 对 CacheDirective 列 表 的 映射 关系 ， 说 明 一 个 文件 /目录 路 径 可 以 同时 被 多 次 缓存 
private final TreeMap<String，List<CacheDirective>> directivesByPath = 
new TreeMap<String, List<CacheDirective>>(); 
// 缓存 池 名 称 对 CachePool 的 映射 
private final TreeMap<String, CachePool> cachePools = 
new TreeMap<String, CachePool>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





以 上 三 大 映射 关系 就 是 CacheManager 中 所 维护 的 。 其 中 第 二 个 关系 缓存 路 径 对 CacheDirective 列 表 的 映射 是 一 开始 笔者 感到 奇怪 的 ， 后 来 发 现 ， 对 同一 个 缓存 路 径 是 可 以 被 多 次 缓存 的 。 由 于 定义 了 
这 三 类 结构 关系 ， 所 以 在 添加 CacheDirective 实 例 对 象 的 时 候 会 涉及 这 些 结构 的 更 新 操作 。 以 addDirective 方 法 为 例 : 








public CacheDirectiveInfo aqddDirective( 
CacheDirectiveInfo info, FSPermissionChecker pc, EnumSet<CacheFlag> flags) 
throws IOException { 
assert namesystem.hasWriteLock(); 
CacheDirective directive; 


try { 
// 获取 所 属 缓存 池 
CachePool pool = getCachePool (validatePoolName (info) ) 7 
// 验证 是 否 有 权限 
checkWritePermission (pc, pool); 
// 验证 缓存 路 径 
String path = validatePath (info); 
// 验证 副本 数 
Short replication = validateReplication (info, (short)1); 
// 验证 过 期 时 间 
long expiryTime = ValidateExpiryTime (info, pool.getMaxRelativeExpiryMs () ) 7 
// 如 果 带 上 了 force 参 数 ， 就 要 验证 CachePool 是 否 还 有 剩余 空间 添加 新 的 缓存 
if (!flags.contains (CacheFlag.FORCE)) { 
checkLimit (pool, path, replication); 


} 

// 获取 下 一 个 Id 

long id = getNextDirectiveId(); 

// 构建 新 的 CacheDirective 实 例 

directive = new CacheDirective(id, path, replication, expiryTime); 
// 进行 添加 操作 


addInternal (directive, pool); 


} catch (IOException e) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
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在 上 面 的 方法 中 ， 有 一 个 步骤 需要 注意 ， 就 是 force 参 数 处 理 时 的 空间 限制 处 理 ， 默 认 情 况 下 CachePool 是 不 受 限 的 。 在 addlnternal 中 会 涉及 存储 关系 的 更 新 : 








Private void addInternal (CacheDirective directive，CachePool Pool) { 
boolean addedDirective = Pool.getDirectiveList () .add (directive); 
assert addedDirective 
// 添加 新 的 id->directive 
directivesById.put (directive.getId(), directive); 

String path = directive.getPath(); 
List<CacheDirective> directives = directivesByPath.get (path); 
if (directives == null) { 
directives = new ArrayList<CacheDirective>(1); 
directivesByPath.put (path, directives); 


// 在 目标 路 径 对 应 的 directives 1ist 中 添加 新 的 directive 
directives.add (directive); 
// 更 新 统计 值 
CacheDirectiveStats stats = 
computeNeeded (directive.getPath(), directive.getReplication()); 
directive.addBytesNeeded (stats.getBytesNeeded ()); 
directive.addFilesNeeded (directive.getFilesNeeded()); 
// 然后 设置 需要 重 扫描 ， 因 为 缓存 目录 已 经 被 更 新 了 


SetNeedsRescan () 








类 似 的 还 有 添加 CachePool 的 操作 ， 代 码 如 下 : 





Public CachePoolInfo adqdCachePool (CachePoolInfo info) 

throws IOException { 

assert namesystem.hasWriteLock(); 

CachePool pool; 

try { 
CachePoolInfo.validate (info); 
// 获取 缓存 池 名 称 
String PoolName = info.getPoolName (); 
Pool = cachePools .get (poolNane); 
7 如 果 获取 到 的 缓存 池 不 为 空 ， 说 明 已 经 存在 ， 抛 异常 
if (pool != null) { 

throw new InvalidRequestException ("Cache Pool " + poolName 
+ " already exists."); 


} 
// 在 默认 缓存 池 的 基础 上 构造 出 新 的 缓存 池 对 象 
Pool = CachePoo] .createFromInfoAndDefaults (info) 
7 添加 到 缓存 池 存储 关系 列表 中 
cachePools .Put (pool .getPoolName (), pool); 
} catch (IOException e) { 
LOG.info("addCachePool of " + info + " failed: ", e); 
throw e; 
} 
LOG.info("addCachePool] of {} successful.", info); 
return pool.getInfo (true); 





当然 在 CacheManager 中 还 有 其 他 修改 缓存 单元 和 列表 操作 的 方法 ， 在 逻辑 上 没有 什么 特别 之 处 ， 这 里 就 不 过 多 地 介绍 了 。 写 到 这 里 ， 再 回 





妙 之 处 的 ， 为 什么 这 么 说 呢 ? 


CacheManager 通 过 id 到 CacheDirective， 路 径 到 CacheDirective 列 表 和 名 称 到 CachePool 的 多 个 映射 关系 ,使 得 原本 逻辑 上 的 父子 关系 
去 找 对 应 的 缓存 对 象 ， 就 不 需要 重新 遍历 查找 了 。 








2.CacheReplicationMonitor 缓 存 监控 服务 





可 头 看 CacheManager 维 护 的 三 种 存储 关系 ， 还 是 有 一 定 的 巧 


结构 平 级 化 了 ， 方 便 了 多 条 件 地 灵活 查询 。 比 如 说 我 们 通过 id 


如 果 把 上 文中 CacheManger 的 缓存 添加 删除 操作 比喻 为 一 个 工厂 中 的 零件 加 工 过 程 ， 那 么 CacheReplicationMonitor 服 务 就 好 比 是 一 个 强大 的 发 动机 ， 它 会 将 这 些 零件 完美 地 处 理 并 分 配 到 对 应 的 车 


间 中 去 。 可 以 说 CacheReplicationMonitor 服 务 是 一 个 指挥 者 的 角色 。 





但 是 这 个 “指挥 者 ”也 同样 被 “大 管家 ”CacheManager 所 掌管 ， 并 控制 着 它 的 开启 与 关闭 。 





public final class CacheManager { 
http :// Www. hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
XY 加 在 管 理 器 中 的 缓存 监控 服务 


private CacheReplicationMonitor monitor; 








缓存 监控 线程 ， 正 如 其 名 称 所 表示 的 含义 : 缓存 副本 块 的 监控 服务 。 因 为 是 一 个 监控 类 型 的 服务 程序 ， 所 以 里 面 通常 会 有 循环 执行 的 操作 逻辑 。 在 CacheReplicationMonitor 中 ， 操 作 的 对 象 是 缓存 








块 ，CacheReplicationMonitor 类 的 定义 如 下 : 


public class CacheReplicationMonitor extends Thread implements Closeable { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 
// 当前 需要 组 存 的 缓存 区 淋 从 
private final GSet<CachedBlock, CachedBlock> cachedBlocks; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





接着 进入 其 中 的 run 方 法 : 





public void run() { 
long startTimeMs = 0; 
Thread. currentThread () .setName ("CacheReplicationMonitor(" + 
System.identityHashCode (this) + ")"); 
LOG.info("Starting CacheReplicationMonitor with interval "+ 
intervalMs + " milliseconds"); 
try { 
long curTimeMs = Time.monotonicNow(); 
// 主 循环 
while (true) { 
lock.lock(); 
J » 
是 否 进行 的 判断 
人 (true) 
// 天 时 守 邓 和 是 否 忆 被 设置 为 停止 状态 
if (shutdown) { 
LOG.info("Shutting down CacheReplicationMonitor"); 
return; 


7 判断 已 扫描 完成 的 块 数 是 否 小 于 需要 完成 的 数目 ， 如 果 是 则 需 
if (completedScanCount < neededScanCount) { 
LOG.debug ("Rescanning because of pending operations"); 
break; 
: 
long delta = (startTimeMs + intervalMs) - curTimeMs; 
if (delta <= 0) { 
LOG.debug ("Rescanning after {} milliseconds", (curTimeMs - startTimeMs)); 











新 进行 rescan 


break; 
} 
doRescan.await (delta, TimeUnit .MILLISECONDS); 
curTimeMs = Time.monotonicNow(); 
} 
} finally { 
lock.unlock (); 
2 


startTimeMs = curTimeMs; 


mark = !mark 
// 执行 新 的 条 区 操作 
Fescan () 7 
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这 里 rescan 方 法 才 是 我 们 最 关注 的 ， 此 方法 的 代码 如 下 所 示 : 





Private void rescan() throws InterruptedException { 
scannedDirectives = 0; 
scannedBlocks = 0; 
try { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 


// 统计 计数 值 

FesetStatistics(7 _ 

// 重新 扫描 缓存 目录 单元 

rescanCacheDirectives () 7 

// 重新 扫描 当前 缓存 块 

rescanCachedBlockMap (); 

blockManager .getDatanodeManager () .resetLastCachingDirectiveSentTime () 7 
finally { 

namesystem.writeUnlock (); 











在 rescan 内 部 ， 会 进行 三 部 分 操作 。 




















第 一 部 分 ，resetstatistics 重 置 统 计 变 量 计 数值 。 因 为 要 进行 完全 新 一 轮 的 缓存 过 程 ， 月 








帮 


所 以 CachePool 以 及 其 所 包含 的 CacheDirective 都 要 重 章 


新 计数 ， 代 码 执行 过 


程 如 下 : 





private void resetStatistics() { 
for (CachePool pool: cacheManager.getCachePools()) { 


for (CacheDirective directive 


} 











// 对 每 个 cachePool 进 行 重 置 计数 
pool.resetStatistics(); 


} 





cacheManager.getCacheDirectives()) { 
// 对 每 个 cacheDirective 进 行 重 置 计数 
directive.resetStatistics () 7 

} 














第 二 部 分 ，rescanCacheDirectives。 在 这 个 过 程 中 会 扫描 之 前 保存 在 CacheManager 中 的 那些 CacheDirectives。 具 体操 作 如 下 : 





private void rescanCacheDirectives() { 
FSDirectory fsDir = | ep 
final long now = new Date( 人 etTime ( 


// 站 


和 


for (CacheDirective directive : cacheManager.getCacheDirectives()) { 


scannedDirectivest++; 

// 跳 过 已 经 过 期 的 缓存 单元 

if (directive.getExpiryTime() > 0 && directive.getExpiryTime () <= now) 
LOG.debug ("Directive {}: the directive expired at {} (now = {})" 

directive.getId(), directive.getExpiryTime(), now); 

continue; 

} 

String path = directive.getPath(); 

INode node; 


册 闪 本 二 
// 获取 缓存 单元 中 缓存 路 径 所 代表 的 INode 对 象 
node = fsDir.getINode (path); 

} catch (UnresolvedLinkException e) { 
// We don't cache through symlinks 


LOG.debug ("Directive {}: got UnresolvedLinkException while resolving " 


+ "path {}", directive.getId(), path 
); 


continue; 
} 
if (node == null) { 
LOG.debug ("Directive {}: No inode found at {}", directive.getId(), 
path); 


} else if (node.isDirectory()) { 
// 如 果 此 路 径 代表 的 是 目录 
INodeDirectory dir = node.asDirectory() 7 
ReadonlyList<INode> children = dir 
.getChildrenList (Snapshot .CURRENT STATE ID); 
for (INode child : children) { re 中 
if (child.isFile()) { 
// 则 扫描 文件 
rescanFile (qirective，child.asFile())7 
} 
} 
} else if (node.isFile()) 
// 后来 是 多 从 负 半 纺 进 生息 撕 1 
rescanFile (directive, node.asFile()); 
} else { 


LOG.debug ("Directive {}: ignoring non-directive, non-file inode {} ", 


directive.getId(), node); 


{ 





这 里 继续 进入 rescanFile 的 操作 方法 : 





private void rescanFile (CacheDirective directive, INodeFile file) { 
// 获取 文件 所 包含 的 块 信息 
BlockInfo[] blockInfos = file.getBlocks(); 


// 增加 文件 需要 数 的 计数 统计 
directive. addFilesNeeded (1) 


// 计算 缓存 需要 的 字 节 大 小 ， RE 





被 写 的 块 





long neededTotal = file.computeFileSizeNotIncludingLastUcBlock() * 


directive.getReplication(); 


directive.addBytesNeeded (neededTotal); 
// 获取 此 存储 对 象 的 所 属 缓存 池 


CachePool pool = directive.getPool () 
// 如 果 绿 存 凶 扩 需要 绥 存 的 空 辣 大 小 超 过 限制 。 则 返回 
if (pool.getBytesNeeded() > pool.getLimit()) { 


LOG.debug ("Directive {}: not scanning file {} because "+ 
"bytesNeeded for pool {} is {}, but the pool's limit is {}", 
directive.getId(), 
file.getFullPathName (), 
pool .getPoolName ()， 
pool .getBytesNeeded () ， 
pool.getLimit ()); 

return; 


} 


long cachedTotal = 0; 
// 遍历 目标 缓存 文件 所 拥有 的 块 
for (BlockInfo blockInfo : blockInfos) { 
if (!blockInfo.getBlockUCState () .equals (BlockUCState.COMPLETE)) { 
// 这 里 不 缓存 正在 被 写 入 数据 的 块 
LOG.trace ("Directive {}: can't cache block {} because it is in state 
+ "{}, not COMPLETE.", directive.getId(), blockInfo, 
blockInfo.getBlockUCState () 


); 


continue; 


} 
// 构造 缓存 块 
Block block = new Block (blockInfo.getBlockId()); 
CachedBlock ncblock = new CachedBlock (block.getBlockId()， 
directive.getReplication(), mark); 
CachedBlock ocblock = cachedBlocks.get (ncblock); 
if (ocblock == null) { 
// 如 果 目 标 缓存 块 列 表 中 不 存在 当前 缓存 块 ， 则 进行 添加 
cachedBlocks .Put (ncblock) 
a ncblock; 
} else 
// 后 末 在 在 ， 则 进行 相关 变量 的 更 新 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
ocblock.setReplicationAndMark (directive.getReplication(), mark); 
} 
} 
LOG.trace ("Directive {}: setting replication for block {} to {}", 
directive.getId(), blockInfo, ocblock.getReplication()); 
让 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 





可 以 将 上 述 操作 归纳 成 下 面 几 个 过 程 : 

1) 获取 缓存 文件 所 拥有 的 块 组 信息 。 

2) 判断 CachePool 的 缓存 大 小 是 否 超过 限制 。 
3) 遍历 块 ， 并 根据 块 构造 缓存 块 。 


4) 如 果 缓 存 块 列 表 中 不 存在 当前 构造 的 缓存 块 则 直接 添加 ， 否 则 进行 部 分 信息 的 更 新 。 





可 能 这 里 有 人 会 有 疑问 ， 为 什么 缓存 块 列表 内 已 经 包含 了 目标 缓存 块 呢 ? 有 两 类 情况 会 导致 此 现象 的 发 生 : 
第 一 种 情况 : 当前 目标 缓存 块 在 上 一 轮 由 于 种 种 条 件 限制 ， 没 有 被 缓存 出 去 ， 所 以 就 没有 被 移 除 掉 
二 种 情况 : 此 缓存 块 已 经 被 缓存 到 DataNode 上 ， 后 来 经 过 DataNode 的 缓存 块 汇报 操作 又 上 报到 CacheManager 的 缓存 列表 中 。 而 CacheReplicationMonitor 处 理 的 正 是 CacheManaget 中 的 缓存 块 列表 。 


既然 缓存 块 列表 已 经 包含 了 目标 缓存 的 块 了 ， 是 否 会 造成 块 的 重复 缓存 ， 从 而 造成 内 存 空间 的 浪费 呢 ? 在 下 面 rescanCachedBlockMap 的 操作 中 ， 我 们 将 寻找 到 答案 。 








第 三 部 分 : rescanCachedBlockMap 操 作 。 此 过 程 是 resan 内 部 3 个 方法 中 逻辑 最 为 复杂 的 操作 ， 下 面 进行 分 段 分 析 。 











首先 会 做 一 些 前 期 的 操作 ， 代 码 如 下 : 





private void rescanCachedBlockMap () 
// 遍历 目标 缓存 块 列表 ， 和 ee 到 bh 些 会 耗 尽 DataNode 缓 存 空间 的 待 缓存 块 
for (Iterator<CachedBlock> cbIter = cachedBlocks.iterator (); 
cbIter.hasNext(); ) { 
scannedBlocks++; 
CachedBlock cblock = cbIter.next(); 
// 获取 不 同 缓存 状态 的 缓存 块 中 的 节点 列表 
List<DatanodeDescriptor> pendingCached = 
cblock.getDatanodes (Type .PENDING CACHED); 
List<DatanodeDescriptor> cached = 
cblock.getDatanodes (Type .CACHED); 
List<DatanodeDescriptor> pendingUncached = 
cblock.getDatanodes (Type.PENDING UNCACHED); 
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然后 根据 上 述 当前 缓存 块 的 不 同 缓存 状态 的 信息 ， 来 计算 当前 块 的 缓存 数目 信息 ， 进 行 下 面 2 部 分 的 处 理 。 
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// 如 果 当 前 缓存 数 已 经 满足 需要 缓存 的 数量 ， 则 移 除 当前 待 缓存 块 
if (numCached >= neededCached) { 
for (Iterator<DatanodeDescriptor> iter = pendingCached.iterator () 7 
iter.hasNext(); ) { 
DatanodeDescriptor datanode = iter.next (); 
datanode .getPendingCached () .remove (cblock); 
iter.remove () 7 
LOG.trace ("Block {}: removing from PENDING CACHED for node {} " 
+ "because we already have {} cached replicas and we only" + 
" need {}", 
cblock.getBlockId(), datanode.getDatanodeUuid(), numCached, 
neededCached 
); 
} 


} 
// 如 果 当 前 缓存 块 还 未 达到 目标 需要 的 缓存 数 ， 则 移 除 待 取消 缓存 的 块 
if (numCached < neededCached) { 
for (Iterator<DatanodeDescriptor> iter = PendingUncached.iterator () 7 
iter.hasNext(); ) { 
DatanodeDescriptor datanode = iter.next (); 
datanode .getPendingUncached () .remove (cblock); 
iter.remove () 7 
LOG.trace ("Block {}: removing from PENDING UNCACHED for node {} " 
+ "because we only have {} cached replicas and we need " 十 
"{}", cblock.getBlockId(), datanode.getDatanodeUuid(), 
numCached, neededCached 


) 7 





然后 添加 还 需要 缓存 的 块 或 还 需要 取消 缓存 的 块 : 





if (neededUncached > 0) { 
// 添加 需要 取消 缓存 的 块 
addNewPendingUncached (neededUncached, cblock, cached, 
pendingUncached); 
} else { 
int additionalCachedNeeded = ee a 
(numCached + pendingCached.size 
DS 
if (additionalCachedNeeded > 0) { 
addNewPendingCached (additionalCachedNeeded, cblock, cached, 
pendingCached); 








如 果 前 面 的 条 件 都 已 经 满足 了 ， 则 当前 正在 进行 遍历 处 理 的 目标 缓存 块 会 被 移 除 掉 ， 表 明 此 块 已 经 成 功 被 缓存 到 DataNode 节 点 上 了 。 





// 如 果 任 何 条 件 都 满足 了 ， 则 对 目标 缓存 块 进行 移 除 
if ((neededCached == 0) && 
pendingUncached.isEmpty() && 
pendingCached.isEmpty()) { 
// we have nothing more to do with this block. 
LOG.trace ("Block {}: removing from cachedBlocks, since neededCached " 
+ "== 0, and pendingUncached and pendingCached are empty.", 
cblock.getBlockId () 
) 7 
cbIter .remove () 7 
} 





以 上 内 容 的 核心 点 在 于 变量 值 neededCached， 而 这 个 值 本 质 上 就 是 目标 缓存 块 的 自身 副本 数 。 所 以 学 习 完 这 部 分 的 过 程 ， 之 前 提出 的 重复 缓存 的 问题 自然 也 就 解决 了 。 对 于 同一 个 缓存 
块 ，CacheReplicationMonitor 服 务 是 不 会 进行 多 余 的 缓存 动作 。 图 2-5 是 rescan 方 法 的 过 程 图 。 











CacheReplicationMonitor 


resetStatistics 





等 待 一 和 | 将 执行 


加 入 
> The Blocks belong to 
时 间 ee 2 


j 7 
将 执行 
加 入 
rescanCachedBlockMap addNewPendingCached 一 The Blocks in CachedBlocks DatanodeDescriptor#pendingCachedList 


图 2-5 ”rescan 过 程 








2.24 ”HDFS 中 心 缓存 疑问 点 


在 HDFS 缓 存 逻 辑 的 实现 过 程 中 ， 笔 者 认为 有 几 处 地 方 在 实现 上 存在 问题 ， 主 要 有 下 面 2 个 疑问 点 : 














第 一 个 疑问 点 ，CacheManager 的 checkLimit 方 法 在 运行 的 时 候 上 默认 副本 数 总 是 为 1。 在 checkLimit 方 法 的 前 面部 分 用 副本 数 计算 字 节 需求 量 : 

















private void checkLimit (CachePool pool, String path, 
short replication) throws InvalidRequestException { 
// 副本 数 作为 参数 传 入 ， 用 以 计算 统计 值 ， 但 是 没有 被 用 上 
CacheDirectiveStats stats = computeNeeded (path, replication); 
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但 其 实在 computeNeeded 方 法 中 副本 数 并 没有 被 用 上 : 





Private CacheDirectiveStats computeNeeded (String path, short replication) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
return new CacheDirectiveStats.Builder() 

// 在 这 个 地 方 理应 是 requestedBytes * replication 
.SetBytesNeeded (requestedBytes) 
.SetFilesCached (requestedFriles) 

‘build(); 





在 上 面 注释 的 地 方 如 果 没 有 用 上 副本 数 ， 就 会 导致 后 面 异常 时 输出 的 信息 有 误 。 执 行 过 程 如 下 : 





private void checkLimit (CachePool pool, String path, 
short replication) throws InvalidRequestException { 
// 副本 数 作为 参数 传 入， 用 以 计算 统计 值 ， 但 是 没有 被 用 上 
CacheDirectiveStats stats = computeNeeded (path, replication); 
if (pool.getLimit() 一 CachePoolInfo.LIMIT UNLIMITED) { 
return; 加 


了 
// 因为 副本 数 没 用 上 ， 在 这 里 需要 乘 上 副本 系数 
if (pool.getBytesNeeded() + (stats.getBytesNeeded() * replication) > pool 
.getLimit()) { 
// 但 是 在 下 面 的 输出 中 又 除了 副本 数 ， 因 此 副本 数 并 没有 乘 上 
throw new InvalidRequestException("Caching Path " + path + " of size 
+ stats.getBytesNeeded() / replication + " bytes at replication 
+ replication + " Would exceed Pool " + pool.getPoolName () 
+ "'s remaining capacity of " 
+ (pool.getLimit() - pool.getBytesNeeded()) + " bytes."); 





























这 个 问题 已 确认 是 一 个 bug， 在 社区 上 已 有 相应 儿 RA: HDFS-10448 (CacheManager#checkLimit always assumes a replication factor of 1) 。 








第 二 个 疑问 点 ，CacheReplicationMonitor 在 缓存 目录 的 时 候 没 有 考虑 到 子 目录 的 情况 ， 只 是 处 理 了 直接 孩子 文件 的 情况 ， 代 码 如 下 : 




















Private void rescanCacheDirectives() { 
FSDirectory fsDir = namesystem.getFSDirectory (); 
final long now = new Date () .getTime () 7 
/广泛 历 级 大 管理 器 中 需要 绥 存 的 基 术 单元 
for (CacheDirective directive : cacheManager.getCacheDirectives()) { 
//http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


if (node =—= null) { 
LOG.debug ("Directive {}: No inode found at {}", directive.getId(), 
path); 


} else 


if (node.isDirectory 


0) 芷 
// 如 果 此 对 象 包含 的 INode 是 目录 的 话 ， 则 遍历 孩子 节点 
INodeDirectory dir = node.asDirectory(); 
ReadonlyList<INode> children = dir 


Lor 
if 


.getChildrenList (Snapshot .CURRENT STATE ID); 
(INode child : children) { 
(child.isFile()) { 


rescanFile (directive, child.asFile()); 


} 
// 
于 
} else 


这 里 缺少 了 孩子 是 目录 的 情况 


if (node.isFile()) { 


// 如 果 此 对 象 包含 的 INode 是 纯 文件 ， 则 直接 进行 处 理 


rescanFile (directive, node.asFile()); 


} else 


i 


LOG.debug ("Directive {}: ignoring non-directive, non-file inode {} ", 
directive.getId(), node); 








后 来 笔者 看 了 官网 的 介绍 ， 目 前 的 版 本 中 只 对 缓存 路 径 下 的 第 一 层 孩 子 做 处 理 ， 并 没有 做 到 对 路 径 的 递归 处 理 。 递 归 处 理 缓存 路 径 是 对 这 种 情况 的 一 个 优化 ， 目 前 社区 已 有 相应 的 JIRA 来 完善 这 一 点 : 


HDFS-10594 ( 


2.2.5 HDFS 


最 后 来 介绍 





HDFS-4949 should support recursive cache directives) ， 感 兴趣 的 同学 可 以 关注 一 下 这 个 JIRA。 














CacheAdmin 命 令 使 用 
HDFS 中 用 于 缓存 块 操作 的 相关 命令 使 用 。 这 些 命令 都 集中 在 hdfs cacheadmin 命 令 下 ， 在 Hadoop 客 户 端 中 输入 如 下 指令 ， 就 会 弹出 所 有 使 用 命令 : 























$ hdfs cacheadmin 
Usage: bin/hdfs cacheadmin [COMMAND] // 以 下 为 hdfs cacheadmin 的 所 有 使 用 命令 


-addDirective -path <path> -pool <pool-name> [-force] [-replication <replication>] [-ttl <time-to-live>]] // 添加 缓存 单元 命令 
-modifyDirective -id <id> [-path <path>] [-force] [-replication <replication>] [-pool <pool-name>] [-ttl <time-to-live>]] // 修改 缓存 单元 命令 
-listDirectives [-stats] [-path <path>] [-pool <pool>] [-iqd <id>] // 列 出 满足 条 件 的 缓存 单元 列表 

-removeDirective <id>] // 删除 指定 id 对 应 的 缓存 单元 

-removeDirectives -path <path>] // 删除 指定 路 径 对 应 的 缓存 单元 

-addPool <name> [-owner <owner>] [-group <group>] [-mode <mode>] [-limit <limit>] [-maxTtl <maxTt1>] // 添加 新 的 缓存 池 

-modifyPool <name> [-owner <owner>] [-group <group>] [-mode <mode>] [-limit <limit>] [-maxTt1 <maxTtl>]] // 修改 缓存 池 

-removePool <name>] // 删除 指定 名 称 缓存 池 

-listPools [-stats] [<name>]] // 列 出 满足 条 件 的 缓存 池 

-help <command-name>] // 查阅 具体 某 条 命令 的 使 用 帮助 信息 





以 上 命令 中 
6 所 示 。 


下 面 演示 一 


首先 ， 我 们 








除了 最 后 一 个 -help 帮 助 命令 之 外 ， 其 余 9 个 命令 都 与 缓存 操作 相关 。 在 这 些 命令 中 ， 还 可 以 划分 为 两 大 类 : 一 类 是 CachePool 相 关 命 令 ， 另 一 类 是 CacheDirective 相 关 命令 。 分 类 图 如 图 2- 








AddCacheDirectiveInfoCommand 





ModifyCacheDirectiveIlnfoCommand 


CacheDirective Commands ListCacheDirectivelnfoCommand 





RemoveCacheDirectivelnfoCommand 


CacheAdmin RemoveCacheDirectivelnfosCommand 


AddCachePoolCommand 


CachePool Commands ModifyCachePoolCommand 





RemoveCachePoolCommand 


ListCachePoolsCommand 





图 2-6 ”HDFS CacheAdmin 相 关 命 令 


下 笔者 在 测试 集群 中 的 操作 结果 。 


需要 新 建 一 个 缓存 池 : 





$ hdfs cacheadmin -addPool zhexuan test pool 
Successfully added cache pool zhexuan test pool. 











然后 用 listPool 命 令 显 示 一 下 是 否 创建 成 功 : 




















$ hdfs cacheadmin -listPools 

Found 1 result. 

NAME OWNER GROUP MODE LIMIT MAXTTL 
Zhexuan test pool data data rwxr-xr-x unlimited never 





这 里 需要 挑选 一 个 目标 缓存 的 文件 或 目录 ， 比 如 下 面 这 个 临时 文件 : 








-rwx 2 zhexuan supergroup 781 2016-04-15 10:51 /tmp/zhexuan file 








调用 addCacheDirective 命 令 并 带 上 必要 的 参数 ， 然 后 加 入 到 刚刚 建 好 的 test_pool 缓 存 池 中 :: 











$ hdfs cacheadmin -addDirective -path /tmp/zhexuan file -pool zhexuan test pool 
Added cache directive 1 





同样 进行 list 查 询 : 


$ hdfs cacheadmin -listDirectives -Pool zhexuan test pool -stats 

Found 1 entr. 

ID POOL REPL EXPIRY PATH BYTES NEEDED BYTES CACHED FILES NEEDED FILES CACHED 
1 zhexuan test pool 1 never /tmp/zhexuan file 781 0 





























以 上 这 些 添加 缓存 池 、 缓 存单 元 的 操作 都 结束 了 之 后 是 否 就 意味 着 操作 结束 了 呢 ? 并 非 如 此 ， 还 有 一 步 很 重要 的 操作 : 开启 DataNode 的 缓存 功能 ， 这 个 功能 默认 是 关闭 的 。 开 启 该 功能 需要 配置 此 属 
































性 值 : 
<property> 
<name>dfs.datanode .max.1locked.memory</name> 
<value>0</value> 
<description> 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
</description> 
</property> 
而 且 这 个 属性 值 要 设 定 符合 机 器 条 件 的 内 存 大 小 ， 以 便 缓存 块 的 存放 。 正 如 上 一 节 末 尾 所 提 到 的 ， 大 家 如 果 能 很 好 地 使 用 HDFS 缓 存 功 能 ,一 定 会 对 集群 的 性 能 提升 有 很 大 的 帮助 。 














2.3 ”HDFS 快 照管 理 





























之 前 章节 中 讲述 了 几 个 最 近 几 年 HDFS 中 比较 重要 的 特性 (比如 异 构 存储 ) ， 本 节 继 续 探讨 另外 一 个 重要 特性 : 快照 (Snapshot) 。 快 照 是 一 个 非常 好 的 东西 ， 快 照 就 好 比 拍 风景 照 时 的 那 一 个 瞬间 的 
投影 ， 过 了 那个 时 间 点 之 后 ， 又 会 有 新 的 一 个 投影 。 所 以 快照 用 一 个 更 好 的 词 来 形容 是 “瞬间 映像 ”。 在 本 节 中 ， 我 们 要 关注 的 焦点 是 HDFS 的 快照 ， 快 照 在 HDFS 中 的 实现 有 其 独特 之 处 。 在 下 文中 ， 我 们 
将 主要 讲述 快照 的 概念 、HDFS 快 照 的 管理 以 及 快照 的 使 用 三 个 方面 的 内 容 。 


























2.3.1 快照 概念 


在 分 析 HDFS 内 部 的 快照 管理 之 前 ， 需 要 先 了 解 快照 的 概念 。 首 先 有 一 个 根本 的 原则 : “快照 不 是 数据 的 简单 拷贝 ， 快 照 只 做 差异 的 记录 。 

















这 一 原则 在 其 他 很 多 系统 的 快照 概念 中 都 是 适用 的 ， 比 如 磁盘 快照 ， 也 是 不 保存 真实 数据 的 。 因 为 不 保存 实际 的 数据 ， 所 以 快照 的 生成 往往 非常 迅速 。 在 HDFS 中 ， 如 果 在 其 中 一 个 目录 比如 /A 下 创建 



































一 个 快照 ， 则 快照 文件 中 将 会 存在 与 /A 目录 下 完全 一 致 的 子 目录 文件 结构 以 及 相应 的 属性 信息 ， 通 过 fs-cat 命 令 也 能 看 到 里 面具 体 的 文件 内 容 。 但 是 这 并 不 意味 着 快照 已 经 对 此 数据 进行 完全 的 拷贝 。 这 里 
遵循 一 个 原则 : 对 于 大 多 不 变 的 数据 ， 你 所 看 到 的 数据 其 实 是 当前 物理 路 径 所 指 的 内 容 ， 而 发 生变 更 的 INode 数 据 才 会 被 快照 额外 拷贝 ， 也 就 是 前 面 所 说 的 差异 拷贝 。 






































2.3.2 ”HDFS 中 的 快照 相关 命令 
































我 们 首先 以 HDFS 暴 露 给 客户 端 使 用 的 命令 作为 一 个 切入 点 ， 看 看 在 HDFS 中 ， 存 在 哪些 与 快照 相关 的 命令 。 通 过 帮助 命令 的 调用 ， 可 以 看 到 在 hadoop fs 命令 下 存在 以 下 快照 操作 命令 : 

















$ hadoop fs 

Usage: hadoop fs [generic options] 
[-createSnapshot <snapshotDir> [<snapshotName>]] // 在 指定 快照 目录 下 创建 快照 
[-deleteSnapshot <snapshotDir> <snapshotName>]  ”// 在 指定 快照 目录 下 删 
[-renameSnapshot <snapshotDir> <oldName> <newName>] // 在 指定 快照 目录 下 











名 某 快照 








还 有 hdfs 命 令 下 的 几 个 命令 : 


$ hdfs 
Usage: hdfs [--config confdir] [~-loglevel loglevel] COMMAND 
where COMMAND is one of: . 
snapshotDiff // 比较 两 个 快照 之 间 的 不 同 或 是 比较 当前 内 容 与 某 快照 之 间 的 不 同 


lsSnapshottableDir ”// 列 出 所 属 当前 用 户 的 所 有 的 快照 目录 






































以 上 两 部 分 总 共 包含 了 6 个 客户 端 命令 ， 通 过 命令 的 名 称 以 及 对 应 的 操作 解释 ， 我 们 大 概 能 明白 其 作用 。 这 些 命令 的 具体 使 用 方法 不 是 本 节 内 容 的 重点 ， 具 体 用 法 可 查阅 Hadoop 官 方 文档 。 
































如 果 大 家 仔细 观察 上 述 的 6 个 命令 ， 可 以 看 出 其 中 主要 围绕 着 两 个 概念 : 








“ 快照 目录 (Snapshottable Directories) 。 
“ 具体 快照 (Snapshot) 。 


上 述 两 个 概念 在 逻辑 上 的 关系 如 下 : 一 个 快照 目录 下 可 以 有 多 个 快照 文件 ， 快 照 目 录 可 以 创建 、 删 除 自身 目录 下 的 快照 文件 ， 同 时 快照 目录 本 身 又 被 快照 目录 管理 器 所 管理 。 





这 里 面 就 引出 了 更 深层 次 的 内 容 : HDFS 内 部 的 快照 管理 机 制 。 


2.3.3 HDFS 内 部 的 快照 管理 机 制 


1. 快 照 结构 关系 
下 面 我 们 从 源码 层面 来 分 析 上 文 提 到 的 对 应 关系 。 


1) 快照 管理 器 管理 多 个 快照 目录 : 





public class SnapshotManager implements SnapshotStatsMXBean { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 快照 目录 映射 图 
private final Map<Long, INodeDirectory> snapshottables = 

new HashMap<Long, INodeDirectory>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








其 实 每 个 快照 目录 就 是 我 们 非常 熟悉 的 INodeDirectory 类 。 





2) 一 个 快照 目录 拥有 多 个 快照 文件 。 快 照 在 快照 目录 中 的 存放 不 是 很 明显 ， 它 是 作为 一 个 额外 属性 存在 于 INodeDirectory 的 父 类 INodeWithAdditionalFields 中 。INodeWithAdditionalFields 内 部 存 
放 有 基本 的 一 些 变量 属性 ， 例 如 名 称 、 权 限 、 最 近 修改 时 间 等 等 ， 代 码 中 的 定义 如 下 : 











public abstract class INodeWithAdditionalFields extends INode 

implements LinkedElement { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
private static final Feature[] EMPTY FEATURE = new Feature[0]; i 
protected Feature[] features = EMPTY FEATURE; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





快照 列表 存在 于 一 个 叫 DirectorySnapshottableFeature 的 Feature 继 承 类 中 ， 源 码 中 的 定义 如 下 : 





public class DirectorySnapshottableFeature extends DirectoryWithSnapshotFeature { 

pe hs ee .Com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 快照 实例 列 

private final List<Snapshot> snapshotsByNames = new ArrayList<Snapshot>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


SnapshotManager#snapshottables 











网 


2-7 显 示 了 前 面 提 到 的 两 大 存放 关系 ， 这 是 本 节 内 容 的 一 个 大 背景 。 















is contained by 





Snapshot Directories 











contains 


is contained by 





snapshotsByNames(List<Snapshot>) DirectorySnapshottableFeature 


is contained by 
INodeDirectory 








extend 


INode.Feature 


图 2-7 快照 结构 


2 快照 调用 流程 





接 下 来 我 们 来 学 习 快 照 的 调用 过 程 ， 整 个 过 程 以 快照 管理 器 (SnapshotManager) 作为 处 理 中 心 。SnapshotManager 负 责 接收 快照 操作 请 求 ， 继 而 调用 相关 类 进行 处 理 。 这 里 的 相关 类 是 
INodeDirectory 中 的 Feature 继 承 类 。 所 以 全 部 过 程 分 为 如 下 两 部 分 : 








1) 上 游 请 求 的 接收 ， 如 图 2-8 所 示 。 














SnapshotManager 








createSnapshot 
deleteSnapshot 


getSnapshottableDirs 


renameSnapshot 


setAllowNestedSnapshots 


图 2-8 ”快照 的 上 游 调用 


2) 请 求 的 下 游 处 理 ， 如 图 2-9 所 示 。 





SnapshotManager 












createSnapshot 


deleteSnapshot 


getSnapshottableDirs 


renameSnapshot 


ETS [oD [See DET El 


图 2-9 快照 的 下 游 处 理 





invoked by 


invoking 


一 罗 


FSDirSnapshotOp 


invoked by 


FSNamesystem 


invoked by 


NameNodeRpcServer 





DirectorySnapshottableFeature 


DirectoryWithSnapshotFeature 





在 上 游 请 求 接收 阶段 中 ， 其 接收 方式 与 以 往 直接 接收 NameNode RPC 请 求 的 方式 略 有 不 同 ， 中 间 还 经 过 了 一 层 FSDirSnapshotOp 类 。 在 这 个 类 中 调用 了 SnapshotManager 的 操作 方法 。 这 样 做 还 是 


有 好 处 的 ， 





可 以 在 FSNamesystem 的 众多 操作 里 很 好 地 辨别 和 区 分 操作 的 类 型 。 


3. 快 照 原理 实现 分 析 


前 面部 
心 的 主要 有 





“快照 


“快照 

















分 主要 从 大 的 角度 来 讲 HDFS 的 快照 管理 ， 而 这 一 小 节 将 要 探讨 快照 的 内 部 原理 实现 ， 将 会 从 更 细 粒 度 的 层面 去 分 析 其 中 的 原理 过 程 ， 其 中 的 部 分 逻辑 还 是 有 些 复杂 的 。 对 于 快照 的 实现 ， 我 们 关 

















如 何 生 成 ， 如 何 能 够 做 到 目录 结构 与 原 目 录 完 全 一 致 ? 


之 间 是 如 何 比 较 出 差异 的 ? 


这 2 个 问题 中 的 每 个 问题 实现 起 来 都 不 是 那么 简单 ， 对 于 下 面 的 分 析 ， 大 家 只 要 理解 就 行 了 。 


快照 的 
权限 。 这 需 





这 个 





创建 操作 是 基于 hadoop fs 的 -createSnapshot 命 令 触发 的 ， 需 要 传 入 2 个 参数 : 快照 所 在 的 父 目 录 名 和 快照 名 称 。 所 以 在 创建 快照 之 前 ， 需 要 先 有 快照 目录 ， 就 是 让 哪些 目录 能 够 有 创建 快照 的 


要 对 目标 目录 执行 allowSnapshot 操 作 。 在 此 操作 执行 的 时 候 ， 记 住 一 个 原则 : 不 允许 创建 出 网 状 关系 的 快照 














条。 

















这 1 


在 进入 





专业 的 术语 说 叫做 NestedSnapshots。 通 俗 的 解释 ， 就 是 目标 快照 目录 的 子 目录 和 父 目 录 不 能 够 同样 为 快照 目录 。 这 个 操作 常常 容易 被 




















最 终 的 createSnapshot 方 法 之 前 ,会 做 一 个 系统 全 局 快照 数 的 判断 : 























户 所 忽略 。 





public String createSnapshot (final INodesInPath iip, String snapshotRoot, 
String snapshotName) throws IOException { 


INodeDirectory 


srcRoot = getSnapshottableRoot (iip); 


if (snapshotCounter 一 getMaxSnapshotID()) { 


// 如 果 快 照 计 数值 达到 最 大 快照 ID， 则 不 允许 创建 快照 ， 寺 





throw new SnapshotException( 
"Failed to create the snapshot. The FileSystem has run out of "+ 


"snapshot IDs and ID rollover is not supported." 


} 


srcRoot .addSnapshot (snapshotCounter, snapshotName); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


f 抛 出 异常 


); 





每 次 新 增 快照 时 ，Counterit 数 会 加 1， 然 后 做 计数 判断 ， 这 里 的 MaxSnapshotlD 指 的 是 上 限 值 : 








public int getMaxSnapshotID() { 
return ((1 << SNAPSHOT ID BIT WIDTH) - 1); 


} 














SNAPSHOT _ID_BIT_WIDTH 值 是 24， 所 以 最 大 的 快照 数 是 2 的 24 次 方 减 1， 基 本 可 以 认为 是 用 不 完 的 。 


继续 进入 createSnapshot 方 法 内 部 : 


// 新 增 快照 方法 











public Snapshot addSnapshot (INodeDirectory snapshotRoot, int id, String name) 
throws SnapshotException, QuotaExceededException { 
// 检查 是 否 已 达 快照 数量 上 限 
final int n = getNumSnapshots (); 
if (n + 1 > snapshotQuota) { 
throw new SnapshotException ("Failed to add snapshot: there are already " 


+ n+™" snapshot(s) and the snapshot quota is 


+ snapshotQuota); 


站 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





可 以 看 到 ， 首 先 会 有 snapshotQuota 的 限制 ， 也 就 是 说 ， 在 每 个 目录 下 又 会 有 快照 总 数 的 限制 。 默 认 的 snapshotQuota 是 2 的 16 次 方 : 





// 单个 快照 目录 允许 创建 快照 的 最 大 数 


static final int 


SNAPSHOT LIMIT = 1 << 16; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 


// 快照 限制 值 


private int snapshotQuota = SNAPSHOT LIMIT; 





接 下 来 是 判断 处 理 : 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 靳 在 快照 对 象 关 
final Snapshot s = new Snapshot (id, name, snapshotRoot); 
final Pe ty nameBytes = s.getRoot() .getLocalNameBytes () 7 


// 检查 是 否 已 


经 存在 同 各 的 快照， 如 果 有 则 抛 异常 


final int i = searchSnapshot (nameBytes) 7 


if (i >= 0) { 
throw new SnapshotException ("Failed to add snapshot: there is already a 
+ "snapshot with the same name \"" 


} 


// 将 此 目录 的 改动 记录 加 入 到 diff 列 表 中 
final DirectoryDiff d = getDiffs() .addDiff (id, snapshotRoot); 
d.setSnapshotRoot (s.getRoot ()); 

snapshotsByNames.add(-i - 1, s); 


// 更 新 快照 目录 的 最 近 修改 时 间 
final long now = Time.now(); 
snapshotRoot .updateModificationTime (now, Snapshot.CURRENT STATE ID); 
Ss.getRoot () .setModificationTime (now, Snapshot .CURRENT STATE ID); 


return s; 


+ Snapshot .getSnapshotName (s) + "\ 














以 下 这 行 操作 ， 会 在 快照 目录 下 的 隐藏 目录 ./snapshot 下 创建 目标 快照 : 





final Snapshot s 


目标 快照 是 创建 好 了 ， 但 是 另外 一 个 问题 来 了 ， 快 照 是 如 何 完全 一 致 地 反映 出 那 一 时 刻 的 文件 目录 信息 呢 ? 而 且 随 着 时 间 的 推移 ， 文 件 目录 早已 发 生 了 改动 ， 快 照 还 是 能 够 保存 当时 时 刻 的 元 信息 数据 


= new Snapshot (id, name, snapshotRoot); 





以 及 对 应 那个 时 间 点 的 真实 数据 ， 这 一 点 也 是 我 们 所 要 关注 的 。 



































一 种 很 自然 联想 到 的 想法 是 HDFS 对 当时 的 文件 目录 的 元 信息 做 了 一 份 拷贝 。 尽 管 这 能 解释 前 面 的 说 法 ， 但 是 如 果 这 种 假设 成 立 的 话 ， 会 衍生 出 一 个 很 大 的 问题 。 当 快照 目录 下 的 数据 文件 在 没有 做 任何 
变动 的 情况 下 ， 过 多 的 快照 创建 无 疑 是 毫 无 意义 并 且 是 浪费 空间 的 ， 会 























显然 在 HDFS 中 不 会 这 么 做 。 所 以 快照 是 文件 目录 元 信息 的 简单 拷贝 是 不 完全 正确 的 。 

















那么 HDFS 到 底 是 怎么 做 的 呢 ? 官方 的 注释 为 : “如 果 当 前 快照 id 不 是 snapshot.CURRENT_STATE ID， 则 从 对 应 的 快照 中 获取 结果 ， 和 否则 从 当前 的 目录 中 获取 结果 。“ 


CURRENT_STATE ID 的 意思 是 当前 快照 的 状态 与 当前 目录 完全 一 致 ， 没 有 发 




















过 文件 目录 信息 的 变动 。 所 以 在 这 种 情况 下 ， 完 全 返回 当前 目录 信息 即 可 ， 换 句 话说 ，Snapshot.CURRENT_STATE ID 








的 意思 就 是 返回 当前 状态 的 目录 信息 。 否 则 从 快照 Id 对 应 的 快照 中 获取 结果 。 从 这 段 注释 中 可 以 提取 出 以 下 关键 信息 : 


每 个 快照 都 有 对 应 


以 上 推论 可 以 从 获 


自身 目录 下 的 INode 信 息 列 表 ， 以 快照 |d 作 为 





区 分 标识 。 





取 子 目录 节点 的 getChildrenList 方 法 中 进行 查阅 : 


public ReadonlyList<INode> getChildrenList (final int snapshotId) { 
DirectoryWithSnapshotFeature sf; 
// 如 果 当 前 快照 Id 是 CURRENF_STATE ID 或 当前 目录 的 快照 特性 为 空 


if (snapshotId 


== Snapshot .CURRENT STATE ID 


， 则 直接 返回 当前 目录 的 子 节点 信息 


11 (sf = this.getDirectoryWithSnapshotFeature()) == nul1) { 
return getCurrentChildrenList (); 


否则 从 对 应 的 快照 中 返回 信息 
return sf.getChildrenList (this, snapshotId); 





sf.getChildrenList 方 法 的 源 代码 如 下 : 





public ReadonlyList<INode> getChildrenList (INodeDirectory currentINode， 
final int snapshotId) { 

// 根据 快照 Id 取出 对 应 目录 的 变更 对 象 信息 

final DirectoryDiff diff = diffs.getDiffBYyId(snapshotId) 


// 如 果 变 更 目录 对 象 为 空 则 直接 返回 当前 目录 的 孩子 信息 ， 和 否则 从 变更 对 象 中 获取 子 节点 列表 
return diff != null ? diff.getChildrenList (currentINode) : currentINode 
.getChildrenList (Snapshot .CURRENT STATE ID); 

















最 后 一 层 是 通过 (变更 ) 信息 获取 子 节点 信息 列表 的 方法 : 





private ReadonlyList<INode> getChildrenList (final INodeDirectory currentDir) { 
return new ReadonlyList<INode>() { 
private List<INode> children = null; 


private List<INode> initChildren() { 
if (children == null) { 
// 获取 变更 的 孩子 信息 
final ChildrenDiff combined = new ChildrenDiff(); 
for (DirectoryDiff d = DirectoryDiff.this; d != null; 
d= d.getPosterior()) { 
combined.combinePosterior (d.diff, null); 


} 

// 与 当前 的 目录 INode 信 息 融 合 ， 构 成 新 的 子 节点 列表 

children = combined.apply2Current (ReadOonlyList .Util.asList( 
currentDir.getChildrenList (Snapshot .CURRENT STATE ID) ) ) 7 


} 


return children; 


} 
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到 这 里 操作 结束 ， 我 们 终于 知道 最 终 的 孩子 列表 是 通过 将 diff 发 生 过 变更 的 INode 信 息 与 原 目 录 节点 信息 进行 结合 ， 然 后 将 一 个 新 的 子 节点 信息 作为 最 终结 果 返 回 。diff 中 保留 的 INode 就 是 当时 快照 创 
建 时 的 INode 信 息 。 








现在 再 仔细 总 结 一 下 整个 逻辑 : 











1) HDFSs 中 只 为 每 个 快照 保存 相对 当时 快照 创建 时 间 点 





生 过 变更 的 INode 信 息 ， 只 是 “ 存 不 同 ”。 

















2) 获取 快照 信息 时 ， 根 据 快照 Id 和 当前 没 发 生 过 变更 的 INode 信 息 ， 进 行 对 应 恢复 。 

















快照 之 间 的 比 差异 功能 对 于 使 用 者 来 说 是 非常 实用 的 功能 。 因 为 通过 比较 不 同时 间 点 创建 的 快照 ， 我 们 可 以 知道 在 此 期 间 到 底 哪 些 文件 目录 被 修改 、 创 建 或 删除 ， 甚 至 还 能 通过 这 些 差异 数据 做 元 数据 
同步 。 快 照 “ 比 差异 ”的 命令 如 下 : 
































hdfs snapshotDiff <path> <fromSnapshot> <toSnapshot> 











在 HDFS 的 快照 中 ， 主 要 有 以 下 4 种 变更 类 型 : 


+: 新 创建 的 文件 /目录 


-: 被 删除 的 文件 /目录 


M: 被 修改 过 的 文件 /目录 









命名 过 的 文件 /目录 


























举 出 HDFS 快 照 官方 介绍 的 一 个 例子 ， 如 果 我 们 重 命名 一 个 目录 “/foo” 到 “/foo2”， 并 且 追 加 新 的 数据 到 文件 “/foo2/bar”， 则 调用 命令 比较 出 的 diff 结 果 将 会 是 如 下 结果 : 




















R./foo->/foo2 
M./foo/bar 


现在 我 们 直接 进入 snapshotDiff 命 令 对 应 的 RPC 处 理 代码 : 








// 快照 差异 比较 方法 
public SnapshotDiffReport diff(final INodesInPath iip, 
final String snapshotRootPath, final String from, 
final String to) throws IOException { 
// 获得 当前 快照 的 根 目录 
final INodeDirectory snapshotRoot = getSnapshottableRoot (iip); 


// 如 果 源 快照 或 目标 快照 为 空 ， 则 直接 构造 出 SnapshotDiffReport 差 异 快照 信息 对 象 
if ((from null || from.isEmpty()) 
&& (to null || to.isEmpty())) { 
// 此 情况 表明 源 快照 、 目 标 快照 与 当前 目录 树 结构 一 致 
return new SnapshotDiffReport (snapshotRootPath, from, to, 
Collections.<DiffReportEntry> emptyList ()); 





} 

// 否则 先生 成 snapshotDiff 信 息 对 象 

final SnapshotDiffInfo diffs = snapshotRoot 
.getDirectorySnapshottableFeature () .computeDiff (snapshotRoot, from, to); 

// 根据 diff 信 息 产 生 报 告 信息 对 象 

return diffs != null ? diffs.generateReport() : new SnapshotDiffReport( 
snapshotRootPath, from, to Collections.<DiffReportEntry> emptyList()); 





以 上 方法 的 处 理 又 可 以 分 为 两 个 过 程 : 


1) 生成 snapshotDifflnfo 对 象 ， 此 对 象 里 面包 含 了 源 、 目 标 快照 间 发 生变 更 的 文件 目录 信息 。 





2) 根据 发 生变 更 的 文件 目录 信息 生成 diff 报 告 ， 展 现 出 的 形式 如 上 述 例子 中 所 示 。 





(1) SnapshotDifflfno 对 象 的 构造 产生 





仔细 观察 上 面 的 2 个 过 程 ， 围 绕 的 核心 对 象 其 实 是 SnapshotDifflnfo， 快 照 对 比 信息 报告 也 是 由 此 对 象 产生 。 进 入 此 类 ， 类 内 部 的 变量 定义 如 下 : 








// 快照 diff 信 息 类 
class SnapshotDiffInfo { 
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// 被 修改 的 文件 、 目 录 对 象 图 ， 按 名 称 进行 排序 
private final SortedMap<INode，byte[] []> diffMap = 
new TreeMap<INode, byte[][]>(INODE COMPARATOR); 
// 被 创建 或 删除 的 文件 列表 图 
private final Map<INodeDirectory, ChildrenDiff> dirDiffMap = 
new HashMap<INodeDirectory, ChildrenDiff>(); 
// 被 重 命名 的 对 象 图 
private final Map<Long, RenameEntry> renameMap = 
new HashMap<Long, RenameEntry>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















从 上 述 变量 及 相应 的 注释 中 可 以 了 解 到 这 里 维护 了 3 大 类 信息 : 
“ 所 有 被 修改 过 的 文件 /目录 ， 不 包括 创建 和 删除 操作 。 
“ 所 有 目录 下 的 被 创建 和 删除 的 子 文件 。 


“ 所 有 被 重 命名 过 的 文件 /目录 信息 。 





所 以 第 一 个 子 过 程 就 是 如 何 找 出 具有 这 些 关系 特征 的 文件 目录 ， 并 加 入 到 这 些 变量 中 ， 答 案 在 下 面 这 行 代码 所 执行 的 操作 中 :: 





final SnapshotDiffInfo diffs = snapshotRoot 
.getDirectorySnapshottableFeature () .computeDiff (snapshotRoot, from, to); 





最 终 执行 的 computeDiff 方 法 的 代码 如 下 : 





Private void computeDiffRecursively (final INodeDirectory snapshotRoot, 
INode node, List<byte[]> parentPath, SnapshotDiffIinfo diffReport) { 
final Snapshot earlierSnapshot = diffReport.isFromEarlier() ? 


diffReport.getFrom() : diffReport.getTo(); 
final Snapshot laterSnapshot = diffReport.isFromEarlier() ? 
diffReport.getTo() : diffReport.getFrom(); 
byte[] [] relativePath = parentPath.toArray (new byte[parentPath.size()][]); 
if (node.isDirectory()) { 


final ChildrenDiff diff = new ChildrenDiff(); 
INodeDirectory dir = node.asDirectory(); 
ae sf = dir.getDirectoryWithSnapshotFeature () 7 
if (sf != null) 
wf 天 旷 现 站 可 下 中 的 指定 目录 是 否 发 生变 化 
boolean change = sf.computeDiffBetweenSnapshots (earlierSnapshot, 
st ok 
if (change) 
// 如 六 和 生 了 改变 ， 就 加 入 到 dirDiff 中 
diffReport.addDirDiff (dir, relativePath, diff); 
} 
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首先 是 判断 目录 的 变化 ， 在 addDirDiff 中 ， 会 更 新 修改 列表 以 及 目录 对 应 的 创建 /删除 子 文件 的 列表 : 

















// 新 增 diff 变 更 对 象 
void addDirDiff (INodeDirectory dir, byte Hy relativePath, ChildrenDiff diff) { 
// 新 增 指定 目录 以 及 对 应 的 创建 /前 除 子 妇 件 和 朋 信息 
dirDiffMap., ut (dir, diff); 
7 新 省 从 成 请 目录 
diffMap.put (i relativePath); 
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然后 是 





命名 关系 的 判断 : 








http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
ReadonlyList<INode> children = dir.getChildrenList (earlierSnapshot 
.getId()); 
for (INode child : children) { 
final byte[] name = child.getLocalNameBytes (); 
boolean toProcess = diff.searchIndex (ListType.DELETED, name) < 0; 
if (!toProcess && child instanceof INodeReference.WithName) { 
byte[] [] renameTargetPath = findRenameTargetPath( 
snapshotRoot, (WithName) child, 
laterSnapshot 一 null ? Snapshot.CURRENT STATE ID : 
laterSnapshot .getId()); 
// 如 果 我 到 量 命 避 对 象 ， 岗 迹 行 重合 名 实体 更 新 
if (renameTargetPath != null) { 
toProcess = true; 
diffReport.setRenameTarget (child.getId(), renameTargetPath); 
} 
} 
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最 后 是 纯 文件 的 变更 判断 : 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} else if (node.isFile() && node.asFile().isWithSnapshot()) { 
INodeFile file = node.asFile(); 
// 判断 快照 中 的 指定 INode 文 件 是 告发 生变 化 
boolean change = file.getFileWithSnapshotFeature () 
.ChangedBetweenSnapshots (file, earlierSnapshot, laterSnapshot); 
// 如 果 发 生变 化 了 则 加 入 到 文件 变更 的 对 象 变量 中 
if (change) { 
diffReport.addFileDiff (file, relativePath); 
$ 
} 








在 addFileDiff 中 也 会 进行 相关 存储 对 象 的 更 新 : 





// 新 增 修改 对 象 

void addFileDiff (INodeFile file, byte[][] relativePath) { 
diffMap.put (file, relativePath); 

} 











需要 注意 的 一 点 是 在 上 述 过 程 中 会 涉及 自身 方法 的 递归 调用 。 这 里 有 一 种 情况 比较 特殊 ， 不 同 快照 之 间 是 如 何 判断 同名 的 目录 或 文件 发 生 了 变更 呢 ， 








这 里 举 文件 变更 判断 为 例子 。 





boolean changedBetweenSnapshots (INodeFile file, Snapshot from, Snapshot to) { 
// 的 人 ef 和 
int[] diffIndexPair = diffs.changedBetweenSnapshots (from, to); 
if (diffIindexPair == null) { 
return false; 
} 
int earlierDiffIndex = diffIndexPair[0]; 
int laterDiffIndex = diffIndexPair[1]; 


final List<FileDiff> diffList = diffs.asList( 

// 家 扣 对 这 区 撒 疝 PieDiEt 下 你 让 刘 当 后 次 时 时 的 祈 生 类 外 ， 进行 文件 大 小 的 判断 

final long earlierLength = diffList.get(earlierDiffIndex) .getFileSize () 7 

final long laterLength = laterDiffIndex == diffList.size() ? file 
:comput Etlosi2o (ere false) : diffList.get (laterDiffIndex) 
getFileSize() 

// 丰 时 新 后 区 生 关 涉 不 下， 则 文件 发 生 了 变更 

if (earlierLength != laterLength) { 

return true; 


上 
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这 里 的 意思 可 能 有 些 人 不 太 理解 ， 之 前 提 到 过 HDFS 只 是 让 每 个 快照 “ 存 不 同 ”， 然 后 以 快照 Id 做 区 分 。 也 就 是 说 ， 对 于 同一 目录 ， 





会 有 多 个 dirDiff (dirDiff 指 的 是 相对 此 快照 发 生 改变 的 INode) ， 这 


些 dirDiff 被 加 入 到 了 DirDiffList 列 表 对 象 中 ， 然 后 根据 快照 Id 作为 下 标 索引 进行 获取 。 同 样 的 在 文件 中 ， 也 存在 单个 快照 的 FileDiff 对 象 以 及 FileDiffList 列 表 项 。 





整个 过 程 如 图 2-10 所 示 。 


(2) SnapshotDifflfno 的 报告 生成 





上 个 过 程 结束 之 后 ，SnapshotDifflfno 就 基本 构造 完成 了 ， 下 面 是 generateReport 的 过 程 了 。 这 个 对 和 象 的 输出 结果 就 是 前 面 快照 diff 命 令 例子 中 所 输出 的 信息 。 进 入 SnapshotDifflnfo 的 


generateReport 方 法 : 


A map recording modified INodeFile and INodeDirectory 





A map capturing the detailed difference about file creation/deletion in each directory 







SnapshotDiffinfo dirDiffMap 
A map recording renamed INodeFile and INodeDirectory 


renameSnapshot 


图 2-10 ”Snapshot 的 di 任 比较 生成 






DirectoryDiffList 
changedBetweenSnapshots 


FileDiffList 





public SnapshotDiffReport generateReport () { 
List<DiffReportEntry> diffReportList = new ArrayList<DiffReportEntry>(); 
// 遍历 修改 列表 对 象 
for (Map.Entry<INode,byte[][]> drEntry : diffMap.entrySet()) { 
INode node = drEntry.getKey(); 
byte[] [] path = drEntry.getValue(); 
// 在 diffReportList 中 新 增 MODIFY 记 录 
diffReportList.add (new Po UY YD path, null)); 
if (node.isDirectory ()) 
// 如 果 是 目录 ， 关 训 着 昌 年 成 报告 处 理 
List<DiffReportEntry> subList = generateReport (dirDiffMap.get (node), 
path, isFromEarlier(), renameMap); 
2 将 结果 加 入 到 di ffReportLi st 列表 中 
diffReportList.addAll (subList); 


} 

// 返回 SnapshotDiffReport 对 象 

return new SnapshotDiffReport (snapshotRoot .getFullPathName (), 
Snapshot .getSnapshotName (from), Snapshot .getSnapshotName (to), 
diffReportList) 7 





从 上 面 的 方法 可 以 看 出 ， 主 要 有 逻辑 是 从 修改 列表 的 遍历 开始 ， 如 果 处 理 的 INode 是 目录 ， 则 继续 递归 处 理 。 生 成 报告 的 方法 如 下 : 








private List<DiffReportEntry> generateReport (ChildrenDiff dirDiff, 
byte[] [] parentPath, boolean fromEarlier, Map<Long, RenameEntry> renameMap) { 
List<DiffReportEntry> list = new ArrayList<DiffReportEntry>(); 
List<INode> created = dirDiff.getList (ListType.CREATED); 
List<INode> deleted = dirDiff.getList (ListType.DELETED); 
byte[] [] fullPath = new byte[parentPath.length + 1][]; 
System.arraycopy (parentPath, 0, fullPath, 0, parentPath.length); 
for (INode cnode : created) { 
RenameEntry entry = renameMap.get (cnode.getId()); 
/7 如果 此 实 称 不 在 renameMap 中 
if (entry 一 null || !entry.isRename()) { 
fullPath[fullPath.length - 1] = cnode.getLocalNameBytes (); 
// 判断 比较 的 顺序 ， 如 果 是 晚 的 快照 与 早 的 快照 相 比 ， 
// 则 created 列 表 中 的 INode 对 象 都 是 CRATE 类 型 ， 否 则 相反 
list.add (new DiffReportEntry (EromEarlier ? DiffType.CREATE 
: DiffType.DELETE, fullPath)); 
} 
} 
for (INode dnode : deleted) { 
RenameEntry entry = renameMap. | getId () ) 
if (entry != null && entry.isRename ()) { 
// 如 果 是 重 名 对 象 ， 则 加 入 RENAME 类 型 的 信息 记录 
list.add (new DiffReportEntry (DiffType.RENAME, 
fromEarlier ? entry.getSourcePath() : entry.getTargetPath(), 
fromEarlier ? entry.getTargetPath() : entry.getSourcePath())); 
} else { 
fullPath[fullPath.length -~ 1] = dnode.getLocalNameBytes () 
// 同样 进行 上 述 逻 辑 判断 ， 如 果 是 前 后 快照 比较 的 话 ， Geletea 的 TNode 部 是 DeLRTE 关 型 的 
list.add (new DiffReportEntry (fromEarlier ? DiffType.DELETE 
: DiffType.CREATE, fullPath)); 





} 
} 
return list; 


} 








在 这 里 ， 就 会 有 其 他 3 种 类 型 的 记录 的 添加 。 在 比较 的 时 候 ， 还 需要 注意 先后 快照 的 比较 顺序 ， 对 于 不 同 顺序 的 比较 ， 所 导致 的 DiffType 是 相反 的 。 以 上 4 种 情况 所 代表 的 标签 符号 如 下 : 





public enum DiffType { 
CREATE ( 
MODIFY ( 
DELETE ( 
RENRAME ("R") 7 
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SnapshotDiffReport 对 象 构 造 完毕 之 后 ， 此 对 象 的 toString 方 法 输出 就 是 命令 返回 的 结果 。 总 的 来 说 ，generateReport 的 过 程 相对 还 是 比较 简单 的 。 


2.3.4 ”HDFS 的 快照 使 用 

















HDFS 的 快照 有 两 大 用 处 ， 下 面 是 具体 的 使 用 场景 : 














“ 丢失 数据 的 恢复 。 这 里 丢失 数据 指 的 是 相对 于 创建 快照 时 间 点 之 后 丢失 的 数据 。 在 HDFS 的 快照 中 ， 只 会 额外 复制 发 生变 更 的 数据 ， 所 以 在 快照 内 部 ， 自 然 会 存在 丢失 数据 的 一 个 备份 ， 这 个 时 候 只 需 


要 将 对 应 快照 文件 目录 拷贝 一 份 即 可 。 


:元 数据 的 差异 比较 。HDFS 的 快照 能 够 提供 diff 比 较 的 功能 。 比 较 的 结果 会 展示 相对 于 源 端 快照 ， 目 标 快照 中 发 生 的 文件 目录 的 变更 记录 。 这 个 差异 结果 可 以 用 于 数据 的 同步 ， 比 如 快照 在 DistCp 命 令 
中 的 使 用 。 用 DistCp 中 的 -diff 参 数 附加 两 个 fom、to 快 照 ， 进 行 元 数据 变更 的 同步 ， 然 后 利用 DistCp 的 功能 ， 进 行 真实 数据 的 拷贝 ， 以 此 实现 集群 数据 间 的 同步 。 这 也 是 HDFS 快 照 的 一 个 很 好 的 使 用 场景 。 


当然 ，HDFS 快 照 还 可 以 有 其 他 使 用 场景 ， 关 键 看 你 怎么 去 利用 这 个 功能 特性 。 


2.4 ”HDFS 副 本 放置 策略 


一 个 文件 块 从 最 初 的 产生 到 最 后 的 沙盘， 会 经 过 存储 类 型 策略 的 选择 ， 在 存储 类 型 选择 策略 中 HDFS 会 帮 有 我们 先 筛选 一 批 符合 存储 类 型 要 求 的 存储 位 置 列 表 ， 通 过 这 些 候 选 列 表 ， 我 们 还 需要 做 进一步 的 
筛选 ， 这 就 是 本 节 所 要 讲述 的 主题 : HDFS 的 副本 放置 策略 。HDFS 的 副本 放置 策略 主要 做 的 事情 在 于 副本 的 最 终 存放 ， 位 置 放 得 好 了 ， 能 提高 读 写 性 能 ， 否 则 反而 会 起 到 负面 的 效果 。 我 们 平常 所 说 的 三 副 
本 备份 策略 就 是 其 中 一 个 副本 放置 策略 。 在 本 节 中 ， 我 们 会 先 讲述 HDFS 放 置 策略 的 概念 ， 然 后 是 HDFS 中 现 有 的 一 些 放置 策略 ， 最 后 我 们 会 以 三 副本 放置 策略 为 例 ， 来 分 析 放 置 策 略 的 实现 原理 。 





2.4.1 副本 放置 策略 概念 与 方法 





首先 要 先 介绍 什么 是 副本 放置 策略 ， 有 些 文章 中 也 会 叫 它 副本 选择 策略 ， 这 源 于 此 策略 的 名 称 : BlockPlacementPolicy。 这 个 策略 类 重 在 副本 放置 (block placement) ， 其 注释 说 明 为 : “选择 期 望 
的 目标 节点 供 副本 块 存放 。” 





上 面 的 注释 已 经 很 清楚 地 表达 了 此 类 型 策略 类 的 用 途 ， 接 下来， 我们 来 看 下 现 有 的 一 些 放置 策略 类 。 





目前 在 HDFS 中 现 有 的 副本 放置 策略 类 有 两 大 继承 子 类 ， 分 别 为 BlockPlacementPolicy-Default 和 BlockPlacementPolicyWithNodeGroup， 继 承 关系 如 图 2-11 所 示 。 


BlockPlacementPolicy BlockPlacementPolicyDefault BlockPlacementPolicyWithNodeGroup 


图 2-11 ”BlockPlacementPolicy 继 承 类 


我 们 平常 提 到 的 三 副本 策略 用 的 是 BlockPlacementPolicyDefault 策 略 类 。 三 副本 如 何 存放 在 这 个 策略 类 中 得 到 了 完美 的 实现 。BlockPlacementPolicyDefault 类 中 的 注释 详细 地 解释 了 三 个 副本 的 存放 
位 置 ， 简 要 概括 起 来 为 以 下 3 点 : 


1) 如 果 写 请 求 方 所 在 机 器 是 其 中 一 个 DataNode， 则 直接 存放 在 本 地 ， 否 则 随机 在 集群 中 选择 一 个 DataNode。 


2) 第 二 个 副本 存放 于 不 同 于 第 一 个 副本 所 在 的 机 架 。 





3) 第 三 个 副本 存放 于 第 二 个 副本 所 在 的 机 架 ， 但 是 属于 不 同 的 节点 。 


总 的 存放 效果 如 图 2-12 所 示 。 








Data Center 


图 2-12 三 副本 策略 放置 位 置 


图 2-12 中 楼 色 区 域 表 示 的 是 写 请 求 者 ， 绿 色 区 域 表示 一 个 副本 。 从 这 里 可 以 看 出 ，HDFS 在 容错 性 上 还 是 做 了 很 多 用 心 的 设计 的 。 








2.4.2 ”副本 放置 策略 的 有 效 前 提 


如 果 机 架 感知 功能 关闭 并 不 会 导致 副本 放置 策略 的 失败 ， 但 是 副本 放置 策略 在 这 种 情况 下 会 失效 。 因 为 在 HDFS 的 副本 放置 策略 中 ， 会 进行 同 机 架 、 不 同 机 架 的 判断 。 如 果 集群 未 开启 机 架 感知 功能 ， 则 
默认 是 同一 个 机 架 ， 就 是 default-rack， 这 会 影响 到 BlockPlacementPolicy 的 逻辑 处 理 。 所 以 在 这 里 需要 开启 这 项 功能 ， 开 启 的 方式 也 很 简单 ， 配 置 如 下 属性 ， 属 性 值 为 能 得 到 节点 机 架 关 系 的 脚本 所 在 路 


径 。 

















<property> 
<name>net .topology.script.file.name</name> 
<value>/path/to/rackAware.py</value> 
</property> 


2.4.3 ”默认 副本 放置 策略 的 分 析 














BlockPlacementPolicyDefault 策 略 类 中 选择 目标 节点 的 处 理 逻 辑 还 是 有 些 复杂 的 ， 下 








的 内 容 会 尽量 简单 易 











对 


























如 有 不 理解 之 处 ， 读 者 可 以 自己 对 照 源码 进一步 学 习 。 








1. 策 略 核心 方法 chooseTargets 


在 默认 放置 策略 类 方法 中 ， 核 心 方法 是 chooseTargets。 但 是 在 这 里 有 2 个 同名 实现 方法 ， 唯 一 的 区 别 是 有 无 favoredNodes 参 数 。favoredNodes 的 意思 是 偏爱 、 喜 爱 的 节点 ， 所 以 此 参数 会 在 一 定 程 
度 上 影响 目标 节点 的 选择 。 这 2 个 方法 的 声明 如 下 : 








大 大 


* 选择 numOfReplicas 个 DataNode 作 为 块 的 目标 结 点 ， 并 且 将 它们 以 Pipeline 的 方式 排序 返 


六 

下 

Public abstract DatanodeStorageInfo[] chooseTarget (String srcPath, 
int numOfReplicas, 
Node writer, 
List<DatanodeStorageInfo> chosen, 
boolean returnChosenNodes, 
Set<Node> excludedNodes, 
long blocksize, 
BlockStoragePolicy storagePolicy); 








/** 

* 与 方法 chooseTarget (String，int，Node，Set，long，List，StorageType) 基 本 类 似 
， 新 添加 了 参数 favoredDatanodes， 表 明 选 择 目标 的 时 候 优先 选择 这 些 节点 

*/ 


DatanodeStorageInfo[] chooseTarget (String src, 
int numOfReplicas, Node writer, 
Set<Node> excludedNodes, 
long blocksize, 
List<DatanodeDescriptor> favoredNodes, 
BlockStoragePolicy storagePolicy); 





在 chooseTargets 传 入 偏爱 的 节点 参数 会 使 得 方法 在 选择 节点 时 候 优先 选取 偏爱 节点 参数 中 的 节点 ， 这 是 此 参数 的 最 根本 的 影响 





然后 是 chooseTarget 无 favoredNodes 参 数 的 实现 过 程 ， 此 方法 最 终 会 进入 到 真正 的 同名 实现 方法 中 。 下 面 将 此 过 程 分 为 了 3 个 子 阶段 。 


1) 初始 化 操作 : 





private DatanodeStorageInfo[] chooseTarget (int numOfReplicas, 
Node writer, 
List<DatanodeStorageInfo> chosenStorage, 
boolean returnChosenNodes, 
Set<Node> excludedNodes, 
long blocksize, 
final BlockStoragePolicy storagePolicy) { 
// 如 果 需 要 的 副本 数 为 0 或 机 器 节点 数量 为 0， 返 回 空 
if (numOfReplicas == 0 || clusterMap.getNumOfLeaves()==0) { 
return DatanodeStorageInfo.EMPTY ARRAY; 


和 

// 创建 移 除名 单列 表 集 

if (excludedNodes == null) { 
excludedNodes = new HashSet<Node> () 7 


上 

// 计算 每 个 机 架 所 允许 的 最 大 副本 数 

int[] result = getMaxNodesPerRack (chosenStorage.size(), numOfReplicas); 

numOfReplicas = result[0]; 

int maxNodesPerRack = result[1]; 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


) 选择 目标 节点 : 





http :// WwW, hzcourse.com/resource/readBook? ath=/ ql cnaour eos/teach ebook/uncompressed/16100/0EBPS/Text/.. 
df 将 所 这 当 i 点 加 入 到 结果 列表 中 ， 同 时 加 入 到 移 除 列表 中 ， 意 为 已 选择 过 的 节 
final List<DatanodeStorageInfo> results = new a 
for (DatanodeStorag: leInfo storage : chosenStorage) { 
// 添加 已 选择 的 节 ;向 到 移 除 列表 中 
addToFxcludedNodes (storage.getDatanodeDescriptor(), excludedNodes); 


1/ 判断 是 否 需要 避免 旧 的 、 未 更 新 的 节点 

boolean avoidStaleNodes = (stats != null 
&& stats.isAvoidingstaleDataNodesForWrite()); 

// 选择 numofRep1licas 副 本 数 的 目标 机 器 ， 并 返回 其 中 第 一 个 节点 

final Node localNode = chooseTarget (numOfReplicas, writer, excludedNodes, 
blocksize, maxNodesPerRack, results, avoidStaleNodes, storagePolicy, 

// 如 果 不 想 返 回 初始 选中 的 目标 节点 ， 则 进行 移 除 

if (!returnChosenNodes) { 

results.removeAll (chosenStorage); 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





3) 对 目标 节点 列表 进行 排序 ， 形 成 Pipeline: 


http: //www. hzcourse. com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 根据 最 短 距离 对 目标 节点 列表 进行 排序 ， 形 成 Pipeline 


return getPipeline( 


(writer != null && writer instanceof DatanodeDescriptor) ? writer 
: localNode, 
results.toArray (new DatanodeStorageInfo[results.size()])); 











在 上 述 的 三 个 子 阶段 中 ， 第 二 阶段 是 最 主要 的 策略 选择 操作 ， 同 样 也 是 最 具 复杂 性 的 ， 所 以 这 里 先 分 析 较 为 简单 的 第 三 个 阶段 的 过 程 。 第 三 个 阶段 的 过 程 为 对 已 经 选择 好 的 目标 节点 存放 位 置 进行 排 
然后 形成 Pipeline 进 行 返回 














Pipeline 形 成 的 过 程 是 传 入 目标 节点 列表 参数 ， 经 过 getPipeline 方 法 的 处 理 ， 然 后 返回 此 Pipeline。 简 要 地 说 ， 就 是 从 writer 所 在 节点 开始 ， 总 是 寻找 相对 路 径 最 短 的 目标 节点 ， 最 终 形成 Pipeline。 学 
习 过 算法 的 同学 应 该 知道 ， 这 其 实 就 是 经 典 的 TSP 旅 行商 问题 。 下 面 是 具体 的 代码 实现 : 






































Private DatanodeStorageInfo[] getPipeline (Node writer, 


DatanodeStorageInfo[] storages) { 
if (storages.length == 0) { 
return storages; 


} 


synchronized (elusterMap) { 
int index=0; 


// 首先 如 果 writer 请 求 方 不 是 来 自 于 集群 中 的 某 一 个 DataNode， 则 上 默认 选取 第 一 个 DataNode 作 为 起 始 节点 
if (writer == null || !clusterMap.contains (writer)) { 
writer = storages[0] .getDatanodeDescriptor (); 


} 


for(; index < storages.length; index++) 
// 获取 当前 index 下 标 所 属 的 go 全 沪 太 和 让 离 的 目标 Storage 


DatanodeStorageInfo shortestStorage = storages[index]; 


// 计算 当前 距离 


int shortestDistance = clusterMap.getDistance (writer, 
shortestStorage.getDatanodeDescriptor ()); 


int shortestIndex = a 


forl(int i = index ; i < storages.length; i++) { 
// 和 当 全 与 放 人 他 二 入 
int currentDistance = clusterMap.getDistance (writer, 
storages[i] .getDatanodeDescriptor ()); 
if (shortestDistance>currentDistance) { 
shortestDistance = currentDistance; 
ShortestStorage = storages[il; 


shortestIindex = i; 
} 


} 
// 找到 新 的 最 短 距离 的 Storage， 并 进行 


if (index != shortestIndex) { 


下 标 蔡 换 


storages [shortestIndex] = storages[index]; 
storages [index] = shortestStorage; 


人 
// 找到 当前 这 一 轮 的 最 近 的 Storage， 并 : 





作为 下 一 轮 迭 代 的 源 节点 


writer = ShortestStorage .getDatanodeDescriptor () 7 


} 


return storages; 


i 





概括 来 说 ， 就 是 选 出 一 个 源 节点 ， 根 据 这 个 节点 ， 遍 历 当前 可 选 的 下 一 个 目标 节 
节点 间 的 距离 和 就 能 保证 是 足够 小 的 了 。 那 么 现在 另外 一 个 问题 还 


点 , 找 出 一 个 


最短 距离 的 节 


节点 ， 作 为 下 一 轮 选举 的 源 节点 。 这 样 每 两 个 节 
没有 解决 : 如何 定义 和 计算 两 个 节点 之 间 的 距离 。 此 距离 的 获取 代码 如 下 : 


节点 之 间 的 距离 总 是 最 近 的 ， 于 是 整个 Pipeline 





clusterMap.getDistance (writer, 


shortestStorage.getDatanodeDescriptor ()); 








要 计算 其 中 的 距离 ， 我 们 首先 要 了 解 HDFS 中 是 如 何 定义 节点 间 的 距离 的 ， 其 中 涉及 拓扑 逻辑 的 概念 ， 如 


level 2 





这 里 显示 的 是 一 个 三 层 结构 的 树 形 效果 图 。 





的 。 每 个 节点 间 的 距离 计算 方式 是 通过 寻找 最 近 公 共 祖 先 所 需要 的 距离 作为 最 终 的 结果 。 比 如 Node1 到 Node2 的 距离 是 2， 就 是 Node1->Rack1， 


distance:2 





图 2-13 所 示 。 


distance:4 














2-13 节点 间距 离 定 义 








Root 可 以 看 做 是 一 个 大 的 集群 ， 下 面 划分 出 了 许多 个 机 架 ， 每 个 机 架 下 面 又 有 很 多 属于 此 机 架 的 节点 。 在 每 个 连接 点 中 ， 是 通过 交换 机 和 路 由 器 进行 连接 


的 距离 就 是 4。 大 家 有 兴趣 的 可 以 学 习 一 下 相关 算法 LCA (最 近 公共 祖先 算法 ) 。 


2.chooseTarget 方 法 主 逻 辑 





下 面 介绍 chooseTarget 主 要 选择 逻辑 。 首 先 ， 务 必要 明确 以 下 几 个 相关 参数 的 作用 和 所 代表 的 含义 : 


Rack1->Node2。 同 理 Rack1 的 Node1 到 Rack2 的 Node1 





final Node localNode = chooseTarget (numOfReplicas, writer, excludedNodes, 
blocksize, maxNodesPerRack, results, avoidStaleNodes, storagePolicy, 
EnumSet .noneOf (StorageType.class), results.isEmpty()) 





“ numOfReplicas: 额外 需要 复制 的 副本 数 。 
“ excludedNodes: 移 除 节点 集合 ， 此 集合 内 
“results: 当前 已 经 选择 好 的 目标 节点 集合 


“storagePolicy:: 存储 类 型 选择 策略 





(1) 首 节 点 的 选择 

















我 们 可 以 对 照 上 文 提 到 的 三 副本 的 存放 方式 。 


求 : 


的 节点 不 应 被 考虑 作为 目标 节点 











首先 是 第 一 个 节点 的 选择 ， 第 一 个 节点 其 





实 是 最 好 选择 的 ， 





为 它 不 











用 考虑 其 他 两 个 节点 的 位 置 ， 但 是 它 要 约束 于 请 求 方 所 在 的 位 置 ， 


这 里 需要 满足 2 个 要 


.如 果 wtitet 请 求 方 本 身 位 于 集群 中 的 一 个 DataNode 之 上 ， 则 第 一 个 副本 的 位 置 就 在 本 地 节点 上 ， 很 好 理解 ， 这 样 直接 就 是 本 地 写 操 作 了 。 如 果 wtitet 请 求 方 来 源 于 外 界 客户 端的 写 请 求 时 ， 则 从 tesult 列 


表 中 挑选 第 一 个 节点 作为 首 个 存放 节点 


“ 如果 result 中 还 是 没有 任何 节点 ， 则 会 从 集群 中 随机 挑选 一 个 节点 作为 第 一 个 节点 。 


相关 执行 代码 如 下 : 








// 如 果 需 要 的 求 副本 数 为 0， 或 者 集群 中 没有 可 选 节 
if (numOfReplicas == 0 || clusterMap. ecbnocieaves 
// 如 果 writer 请 求 者 在 其 中 一 个 datanode 上 则 返回 此 节 伏 册 可 失 让 加 ul 


return (writer instanceof DatanodeDescriptor) 二 writer : null; 


7 获取 已 经 选择 完成 的 节点 数 

final int numOfResults = results.size(); 

// 计算 期 望 达到 的 副本 总 数 

final int totalReplicasExpected = numOfReplicas + numOfResults; 

// 如 果 writer 为 空 或 不 在 DataNode 上 ， 则 取出 已 选择 列表 中 的 第 一 个 位 置 所 在 节点 ， 赋 值 给 writer 

if ((writer == null || !(writer instanceof DatanodeDescriptor)) && !newBlock) { 
writer = results.get (0) .getDatanodeDescriptor () 7 


} 


// 做 一 份 移 除 列表 名 单 的 拷贝 
final Set<Node> oldExcludedNodes = new HashSet<Node> (excludedNodes); 


// 根据 存储 策略 获取 副本 需要 满足 的 存储 类 型 列表 ， 如 果 有 不 可 用 的 存储 类 型 ， 会 采用 fallback 情 况 下 的 
storageType 类 型 
final List<StorageType> requiredStorageTypes = storagePolicy 
.ChooseStorageTypes ( (short) totalReplicasExpected, 
DatanodeStorageInfo.toStorageTypes (results), 
unavailableStorages, newBlock); 
// 将 存储 类 型 列表 进行 计数 统计 ， 并 存 于 map 中 
final EnumMap<StorageType, Integer> storageTypes = 
getRequiredStorageTypes (requiredStorageTypes); 
if (LOG.isTraceEnabled()) { 
LOG.trace ("storageTypes=" + storageTypes); 
} 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





(2) 三 副本 位 置 的 选取 











下 面 是 三 副本 存储 位 置 的 选取 过 程 ， 需 要 与 图 2-1 


DD 











展示 的 存放 方式 进行 对 照 ， 会 好 理解 一 些 。 








点 都 属于 一 个 默认 机 架 (default-rack) ， 会 导致 chooseRemoteRack 的 方法 出 错 ， 因 为 没有 满足 条 件 的 其 余 机 架 。 这 时 需要 一 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 


// 如 果 numOfReplicas 或 requiredStorageTypes 大 小 为 0， 则 抛 出 异常 
try { 
if ((numOfReplicas = requiredStorageTypes.size()) == 0) { 
throw new NotEnoughReplicasException( 
"All required storage types are unavailable: 
+ " unavailableStorages=" + unavailableStorages 
+ ", storagePolicy=" + storagePolicy); 


} 
// 如 果 已 选择 的 目标 节点 数量 为 %0， 则 表示 三 副本 一 个 都 还 没 开 始 选 ， 首 先 从 选 本 地 节点 开始 
if (numOfResults == 0) { 
writer = chooseLocalStorage (writer, excludedNodes, blocksize, 
maxNodesPerRack, results, avoidSstaleNodes, storageTypes, true) 
etDatanodeDescriptor ( 
人 如 时 二 困 上 和 革 守成 和 代表 选择 目标 完成 ， 返 回 第 一 个 节点 writer 
if (--numOfReplicas 一 
return writer; 


} 


} 
// 取出 result 列 表 第 一 个 节点 
final a dn0 = results.get (0) .getDatanodeDescriptor (); 
// 前 面 的 过 程 已 经 完成 fe 点 的 选择 ， 此 时 进行 不 同 机 架 的 节点 选择 
if (numOfResults 人 
// 选择 1 个 不 同 时 0 所 在 各 房 的 一 个 目标 点 位 置 
chooseRemoteRack (1, dn0, excludedNodes, blocksize, maxNodesPerRack, 
results, avoidStaleNodes, storageTypes); 
// 如 果 此 时 目标 需求 完成 的 副 人 六 代表 移 择 目标 完成 ， 返 回 第 一 个 节点 writer 
if (--numOfReplicas == 0) 
return writer; 


} 


7/ 如 果 经 过 前 面 的 处 理 ， 节 点 选择 数 在 2 个 以 内 ， 需 要 选取 第 三 个 副本 
if (numOfResults <= 2) { 
// 取出 result 列 表 第 二 个 节点 
final DatanodeDescriptor dnl = results.get (1) .getDatanodeDescriptor () 7 
// 如 果 dn0、dn1 在 同 机 房 
if (clusterMap.isOnSameRack (dn0, dn1) 
// 则 选择 1 个 不 同 于 dn0， 7 记 生计 入 的 央 未 位置 
chooseRemoteRack (1, dn0, excludedNodes, blocksize, maxNodesPerRack, 
results, avoidStaleNodes, storageTypes); 
} else if (newBlock){ 
// 如 果 是 新 的 块 ， 荐 妆 取 3 个 与 4n1 同 机 房 的 节 i 位 置 
ChooseLocalRack (dnl1l, excludedNodes, blocksize, maxNodesPerRack, 
tp avoidStaleNodes, storageTypes); 
} else 
// 生出 选取 与 wciter 同 机 房 的 位 轩 
ChooseLocalRack (writer, excludedNodes, blocksize, maxNodesPerRack, 
results, avoidStaleNodes, storageTypes); 


} 
// 如 果 此 时 目标 需求 完成 的 副本 数 降 为 0， 代 表 选 择 目标 完成 ， 返 回 第 一 个 节点 writer 
if (--numOfReplicas == 0) { 

return writer; 


} 


7 如 果 副 本 数 已 经 超过 2 个 ， 说 明 设置 块 时 已 经 设置 超过 三 副本 的 数量 

// 则 剩余 位 置 在 集群 中 随机 选择 放置 节 

chooseRandom (numOfReplicas, 0 excludedNodes, blocksize, 
maxNodesPerRack, results, avoidStaleNodes, storageTypes); 









































如 果 看 完 这 段 逻 辑 ， 你 还 不 理解 的 话 ， 没 有 关系 ， 只 要 明白 经 典 的 三 副本 存放 位 置 ， 多 余 的 副本 随机 存放 的 原理 即 可 。 




















if (retry) { 
for (DatanodeStorageInfo resultStorage : results) { 
addToExcludedNodes (resultStorage .getDatanodeDescriptor ()， 
oldExcludedNodes); 


} 

// 剔除 之 前 选择 完成 的 目标 位 置 ， 重 新 计算 当前 需要 复制 的 副本 数 

numOfReplicas = totalReplicasExpected - results.size(); 

// 重新 调用 自身 方法 进行 复制 块 目标 节点 的 选择 

return chooseTarget (numOfReplicas, writer, oldExcludedNodes, blocksize, 
maxNodesPerRack, results, false, storagePolicy, unavailableStorages, 
newBlock); 











当然 在 选择 的 过 程 中 可 能 会 发 生 异 常 ， 有 时 我 们 没有 配置 机 架 感 知 ， 集 群 中 的 节 








试 策略 ， 代 码 如 下 所 示 : 








(3) chooseLocalStorage、chooseLocalRack、chooseRemoteRack 和 chooseRandom 方 法 


这 4 个 选择 目标 节点 位 置 的 方法 是 一 个 优先 级 逐 级 降低 的 方法 。 首 先 选择 本 地 存储 位 置 ， 如 果 没 有 满足 条 件 的 节点 ， 再 选择 本 地 机 架 的 节点 ， 如 果 还 
节点 ， 最 后 随机 选择 集群 中 的 节点 。 降 级 选择 过 程 见 图 2-14。 

















是 没有 满足 条 件 的 节 


点 ， 进 一 步 降级 选择 不 同 机 架 的 
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图 2-14 选择 节点 操作 




















加 











但 是 这 里 还 是 要 区 分 一 下 chooseLocalStorage 方 法 。 此 方法 与 其 余 的 3 个 方法 稍 显 不 同 ， 它 是 单独 实现 的 ， 而 其 余 的 方法 是 通过 传 入 不 同 参数 直接 或 间接 调用 chooseRandom 方 法 进行 构造 的 。 





首先 来 看 chooseLocalSstorage 方 法 实现 : 




















protected DatanodeStorageInfo chooseLocalStorage (Node localMachine, 

Set<Node> excludedNodes, long blocksize, int maxNodesPerRack, 
List<DatanodeStorageInfo> results, boolean avoidSstaleNodes, 
EnumMap<StorageType, Integer> storageTypes, boolean fallbackToLocalRack) 
throws NotEnoughReplicasException { 

// if no local machine, ey choose one node 

if (localMachine == null) 
// 如 果 本 地 节点 为 空 ， 贡 承 级 选择 个 随机 节点 
return chooseRandom (NodeBase.ROOT, excludedNodes, blocksize, 

maxNodesPerRack, results, avoidSstaleNodes, storageTypes); 





. 
if (preferLocalNode && localMachine instanceof DatanodeDescriptor) { 


DatanodeDescril oT localDatanode = (DatanodeDescriptor) localMachine; 
// 否则 尝试 选择 本 地 节点 
if (excludedNodes.add (localMachine)) { 





如 果 本 地 节点 没有 被 包含 在 移 除 列表 中 ， 则 进行 下 面 的 操作 : 





for (Iterator<Map . Integer>> iter = storageTypes 
.entrySet () .iterator(); iter.hasNext(); ) { 
Map.Entry<StorageType, Integer> entry = iter.next(); 
/六 党 访 林 他 认可 用 的 各 亿 目 如 
for (DatanodeStorageInfo i : DFSUtil.shuffle( 
localDatanode.getStorageInfos())) { 
StorageType = entry.getKey (); 
/7 久 请 赴 条 伯 则 和 久生 训 人 3 
if (addIfIsGoodTarget (localStorage, excludedNodes, blocksize, 
maxNodesPerRack, false, results, avoidstaleNodes, type) >= 0) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 本 地 节点 没有 满足 条 件 的 存储 位 置 ， 则 降级 选取 同 机 架 的 节点 
return chooseLocalRack (localMachine, excludedNodes, blocksize, 
maxNodesPerRack, results, avoidstaleNodes, storageTypes); 








chooseLocalRack 和 chooseRemoteRack 比 较 类 似 。 


chooseLocalRack 方 法 如 下 : 





// 没有 本 地 节点 ， 则 选择 一 个 随机 的 节点 
if (localMachine == null) { 
return chooseRandom (NodeBase.ROOT, excludedNodes, blocksize, 
maxNodesPerRack, results, avoidSstaleNodes, storageTypes); 


} 
// 获取 本 地 机 架 名 


final String localRack = localMachine.getNetworkLocation (); 


try { 
// 将 机 架 名 作为 scope 参 数 传 入 
return chooseRandom (localRack, excludedNodes, 
blocksize, maxNodesPerRack, results, avoidStaleNodes, storageTypes); 





chooseRemoteRack 的 方法 如 下 : 





// 获取 本 地 机 架 名 称 ， 带 上 前 级 字符 ~~“， 作 为 scope 参 数 传 入 

chooseRandom (numOfReplicas, "~" + localMachine.getNetworkLocation(), 
excludedNodes, blocksize, maxReplicasPerRack, results, 
avoidStaleNodes, storageTypes); 














从 这 里 我 们 可 以 看 到 ， 其 中 最 明显 的 区 别 是 chooseRandom 中 scope 参 数 的 传 入 ，scope 参 数 的 作用 是 选择 出 属于 此 机 架 下 的 节点 列表 。 








DatanodeDescriptor chosenNode = 
(DatanodeDescriptor) clusterMap.chooseRandom (scope); 














在 NetworkTopology 下 是 其 具体 的 实现 : 





/x 
* 从 scope 所 示范 围 中 随机 选取 一 个 节点 ， 如 果 scope 以 字符 ~” 打头 ， 则 从 非 scope 范 围 
i 


public Node chooseRandom(String scope) { 
netlock.readLock() .lock (); 
try { 
if (scope.startsWith("~")) { 
return chooseRandom (NodeBase.ROOT, scope.substring(1)); 
} else { 
return chooseRandom(scope, null); 
i 
} finally { 
netlock.readLock() .unlock (); 
了 





具体 的 实现 细节 ， 读 者 可 以 自行 研究 。 机 架 节点 选择 好 之 后 ， 接 着 会 进行 Storage 存 储 位 置 的 选择 判断 ， 然 后 加 入 到 result 目 标 列表 中 。 


2.4.4 ”目标 存储 好 坏 的 判断 


如 果 块 放置 节点 已 经 初步 选择 好 了 ， 是 否 意味 着 此 位 置 就 可 以 加 入 最 终 的 result 列 表 中 呢 ? 答案 是 否定 的 ， 因 为 这 里 还 要 经 过 最 后 一 道 对 于 存储 的 验证 (这 里 要 明确 一 点 : 目标 位 置 result 类 别 存储 的 对 
象 是 DatanodeStoragelnfo， 这 个 类 表示 的 是 具体 到 节点 存储 磁盘 目录 级 别 的 信息 ， 并 不 是 广义 上 的 节点 ) ， 需 要 满足 以 下 几 个 条 件 : 

















“ 存储 的 存储 类 型 必须 是 请 求 的 存储 类 型 。 

“ 存储 不 能 是 READ_ONLY (只 读 ) 。 

“ 存储 不 能 是 坏 的 。 

“ 存储 所 在 节点 不 应 该 是 已 下 线 或 下 线 中 的 节点 。 

“ 存储 所 在 节点 不 应 该 是 消息 落后 的 节点 ， 实 际 指 的 是 一 段 时 间 内 没有 更 新 心跳 的 节点 。 
“ 节点 内 保证 有 足够 的 剩余 空间 能 满足 写 块 所 要 求 的 大 小 。 

: 要 考虑 节点 的 IO 负载 繁忙 程度 。 


“ 要 满足 同 机 架 内 最 大 副本 数 的 限制 。 





可 见 验证 的 条 件 还 是 非常 苛刻 的 ， 具 体 代码 见 BlockPlacementPolicyDefault 的 isGoodTarget 方 法 。 


2.4.5 ”chooseTargets 的 调用 


chooseTargets 的 调用 分 为 有 favoredNodes 参 数 和 无 favoredNodes 参 数 两 类 。 


无 参数 的 chooseTargets 主 要 被 BlockManager 对 象 所 调用 ， 如 图 2-15 所 示 。 











chooseTarget4AdditionalDatanode 






invoke by 
belong to 





chooseTarget4WebHDFS 








BlockManager 





chooseTarget(without favoredNodes) 


ReplicationWork 











图 2-15 ”chooseTargets 无 favoredNodes 参 数 调用 


















































其 中 RepliactionWork 主 要 做 的 工作 是 将 集群 中 待 复制 的 副本 块 下 发 到 对 应 的 DataNode 上 。 带 favoredNodes 参 数 的 调用 则 是 由 外 界 主动 设置 的 ， 调 用 场景 如 图 2-16 所 示 。 








chooseTarget(with favoredNodes) 











设置 到 





DFSClient.favoredNodes DFSOutputStream.DataStreamer chooseTarget4NewBlock 


NameNodeRpcServer.addBlock 











2-16 ”chooseTargets 带 favoredNodes 参 数 调用 





favoredNodes 的 源头 是 DFSClient 客 户 端 主动 设置 的 ， 然 后 创建 到 DFSOutputStream 的 DataStreamer 中 ， 被 后 续 方 法 所 调 
传 入 的 ， 代 码 如 下 : 





用 。 但 是 DFSClient 在 创建 默认 DFSOutputStream 时 是 不 带 favoredNodes 








public DFSOutputStream create (String src, 
FsPermission permission, 
EnumSet<CreateFlag> flag, 
short replication, 
long blockSize, 
Progressable progress, 
int buffersize, 
ChecksumOpt checksumOpt) 

throws IOException { 
return createl(src, permission, flag, true, 
replication, blockSize, progress, buffersize, checksumOpt, null); 








最 后 一 个 null 就 是 传 入 的 favoredNodes 参 数 。 其 实 传 入 的 favoredNodes 更 多 的 是 一 种 期 望 ， 最 后 并 不 一 定 能 被 NameNode 真 正 存放 。 因 为 中 间 会 经 过 很 多 因 
平衡 ) 的 过 程 中 ， 某 些 块 还 是 会 被 挪 走 ， 就 不 会 按照 原来 的 位 置 存放 。 








素 的 影响 ， 而 且 在 后 面 的 Balance (数据 





2.4.6 _ BlockPlacementPolicyWithNodeGroup 继 承 类 


BlockPlacementPolicyWithNodeGroup 是 BlockPlacementPolicyDefault 的 继承 子 类 。 前 者 与 后 者 在 原理 上 十 分 类 似 ， 不 过 在 逻辑 上 从 机 架 是 否 相同 的 判断 变 为 了 是 否 为 同 个 Node-Group 的 判断 ， 
详细 解释 可 阅读 其 源码 注释 。 








它 是 一 个 四 层 层级 结构 ， 在 Rack 机 架 层 下 还 多 了 Node-Group 层 ， 结 构图 如 图 2-17 所 示 。 
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图 2-17 NodeGroup 的 拓扑 结构 


由 于 与 其 父 类 的 逻辑 没有 很 大 差别 ， 这 里 就 不 展开 讲述 了 。 


2.4.7 ”副本 放置 策略 的 结果 验证 








如 果 一 个 副本 块 最 终 完成 了 所 有 的 写 操作 并 且 已 经 完全 存 入 到 相应 的 DataNode 中 了 ， 这 时 我 们 如 何 验 证 三 副本 存放 策略 的 有 效 性 呢 ? 换 句 话说 ， 我 们 需要 有 一 种 方式 能 够 检测 块 当前 的 详细 位 置 ， 这 
样 我 们 才能 判断 是 否 满足 HDFS 的 副本 放置 策略 。 这 里 介绍 一 个 相关 的 检测 命令 : fsck。fsck 命 令 是 专门 用 于 做 块 检查 的 命令 。 执 行 如 下 命令 可 以 得 到 文件 所 属 块 的 详细 位 置信 息 。 



































hdfs fsck <path> -files -blocks -locations 





以 上 内 容 就 是 本 节 所 要 讲述 的 HDFS 放 置 策略 的 内 容 了 ， 在 内 容量 上 可 能 有 点 多 ， 希 望 大 家 通过 此 节 内 容 的 学 习 能 对 HDFS 的 三 副本 策略 以 及 背后 的 放置 策略 有 更 深 的 了 解 。 


2.5 ”HDFS 内 部 的 认证 机 制 


























数据 的 安全 性 是 一 直 被 大 家 所 重视 的 。 对 于 一 个 存 有 大 规模 数据 的 成 熟 企业 来 说 ， 如 何 做 到 数据 不 丢失 、 不 损坏 、 不 窃取 是 十 分 重要 的 。 如 果 我 们 用 HDFS 存 储 大 规模 的 数据 ， 如 何 保证 其 中 数据 的 安全 
性 呢 ? 本 节 我 们 将 介绍 HDFS 内 部 两 大 认证 机 制 : BlockToken 认 证 和 Sasl 认 证 。 这 两 个 认证 机 制 在 一 定 程度 上 能 起 到 数据 保护 的 作用 。BlockToken 认 证 是 基于 令 牌 的 块 级 别 粒度 的 验证 ， 而 Sasl 认 证 则 是 标 
准 的 Sasl 认 证 机 制 在 HDFS 中 的 具体 实现 。 在 本 节 的 最 后 ， 我 们 会 对 这 两 大 机 制 做 一 个 简单 的 比较 ， 让 大 家 更 加 清晰 地 了 解 二 者 的 异同 。 












































2.5.1 ”BlockToken 认 证 











相 比 较 而 言 ，BlockToken 认 证 比 Sasl 认 证 要 简单 一 些 ,而 且 BlockToken 在 Sasl 认 证 中 也 会 用 到 。 细 看 BlockToken 这 个 词 ， 可 以 将 其 拆 分 为 两 个 词 : Block 和 Token， 由 此 我 们 可 以 得 出 以 下 两 点 关键 信 
息 : 

















' BlockToken 是 针对 块 级 别 的 认证 。 


“Token 是 “ 令 牌 ”的 意思 ， 通 常 是 用 做 访问 时 的 认证 。 





大 体 有 了 这 么 一 个 了 解 之 后 ， 接 下 来 看 BlockToken 机 制 是 如 何 做 具体 认证 的 ， 要 完全 理解 这 个 问题 ， 需 要 弄 清楚 以 下 三 点 : 
“ BlockToken 如 何 生成 ? 
' BlockToken 在 哪里 认证 ? 


* BlockToken 如 何 认证 ? 


1.BlockToken 的 结构 分 析 





BlockToken 的 结构 分 析 可 以 帮助 我 们 了 解 它 是 如 何 产生 的 。 如 果 你 仔细 观察 和 查找 ， 应 该 很 容易 就 找到 相关 类 : BlockPoolTokenSecretManager。BlockToken 就 是 由 这 个 类 调用 产生 的 。 但 是 真正 
产生 BlockToken 的 操作 实质 上 是 由 其 存储 的 BlockTokenSecretManager 类 做 的 。 所 以 这 些 类 的 关系 为 : BlockPoolTokenSecretManager 包 含 BlockTokenSecretManager， 并 且 每 一 个 BlockPool 对 应 一 


个 BlockTokenSecretManager。 








最 终 是 如 下 的 存储 映射 关系 : 





private final Map<String, BlockTokenSecretManager> map = 
new HashMap<String, BlockTokenSecretManager>(); 














可 能 会 有 人 有 问 ， 为 什么 按照 BlockPool 分 出 这 么 多 的 BlockTokenSecretManager， 全 局 维护 一 个 Manager 不 是 更 好 吗 ? 笔者 的 个 人 看 法 是 HDFS 这 么 做 还 是 想 做 隔离 ，BlockPool 是 在 每 次 
NameNode 做 format 时 产生 的 ， 代 表 着 独立 的 存储 空间 和 命名 空间 。 所 有 的 块 在 各 自 所 属 的 BlockPool 下 是 全 局 唯一 的 ， 每 个 BlockPool 下 的 块 也 是 由 独立 所 属 的 BlockManager ( 块 管理 器 ) 进行 管理 。 
HDFS 中 是 可 以 有 多 个 BlockPool 的 。 回 到 前 面 说 的 过 程 ， 继 续 来 看 BlockToken 的 生成 调用 过 程 。 









































// Token 生 成 方法 
public Token<BlockTokenIdentifier> generateToken (ExtendedBlock b, 
EnumSet<AccessMode> of) throws IOException { 
// 选择 块 所 属 的 BlockPool 去 生成 Token 
return get (b.getBlockPoolId()) .generateToken (b, of); 
} 











实际 的 调用 方法 如 下 所 示 : 











public Token<BlockTokenIdentifier> generateToken (ExtendedBlock block, 
EnumSet<BlockTokenIdentifier.AccessMode> modes) throws IOException { 
UserGroupInformation ugi = UserGroupInformation.getCurrentUser (); 
String userID = (ugi 一 null ? null : ugi.getShortUserName () ) 7 
return generateToken (userID, block, modes); 


} 


// 生成 Token 最 终 调用 方法 
public Token<BlockTokenIdentifier> generateToken (String userId 
ExtendedBlock block, EnumSet<BlockTokenIdentifier.AccessMode> modes) throws IOException { 
// 将 块 相关 信息 、 用 户 信息 、 访 问 模式 信息 设置 入 BlockToken 对 象 中 ， 并 返回 
BlockTokenIdentifier id = new BlockTokenIdentifier (userId, block 
.getBlockPoolId(), block.getBlockId(), modes); 
return new Token<BlockTokenIdentifier>(id, this); 


} 

















BlockToken 在 创建 块 的 时 候 会 被 构建 : 





private LocatedBlock createLocatedBlock (final BlockInfo blk, final long pos, 
final AccessMode mode) throws IOException { 
final LocatedBlock lb = createLocatedBlock (blk, pos); 
// 设置 BlockToken 
if (mode != null) { 
setBlockToken (lb, mode); 


return lb; 





setBlockToken 方 法 的 代码 如 下 : 





Public void setBlockToken (final LocatedBlock b, 
final AccessMode mode) throws IOException { 
// 如 果 开启 了 BlockToken 认 证 功能 
if (isBlockTokenEnabled()) { 





// Use cached UGI if serving RPC calls. 
if (b.isStriped()) { 
Preconditions .checkState (b instanceof LocatedStripedB1ock) 
LocatedstripedBlock sb = (LocatedStripedBlock) b; 
byte[] indices = sb.getBlockIndices(); 
Token<BlockTokenIdentifier>[] blockTokens = new Token[indices.length]; 
ExtendedBlock internalBlock = new ExtendedBlock (b.getBlock()); 
for (int i = 0; i < indices.length; i++) { 
internalBlock. setBlockId (b.getBlock() .getBlockId() + indices[i]); 
// 生成 BlockToken 对 象 
blockTokens[i] = blockTokenSecretManager .generateToken( 
NameNode .getRemoteUser () .getShortUserName (), 
internalBlock, EnumSet .of (mode)); 
. 
sb.setBlockTokens (blockTokens); 
} else { 
// 生成 BlockToken 对 象 并 设置 到 块 
b.setBlockToken (blockTokenSecretManager .generateToken ( 
NameNode .getRemoteUser () .getShortUserName ()， 
b.getBlock(), EnumSet .of (mode))); 


于 











这 就 是 BlockToken 从 产生 到 被 设置 到 目标 对 象 的 过 程 。 注 意 上 述 代码 中 的 一 个 细节 处 理 ， 即 加 粗 的 代码 。 也 就 是 说 ，BlockToken 功 能 是 可 控 的 ， 它 是 一 个 受 配 置 控制 的 功能 ， 具 体 的 配置 项 后 面 会 具 
体 说 明 。 综 上 所 述 ， 在 这 个 部 分 我 们 基本 上 了 解 了 BlockToken 相 关 的 结构 设计 以 及 相关 的 方法 ， 如 图 2-18 所 示 。 
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图 2-18 ”BlockToken 相 关 结 构 


2.BlockToken 的 调用 与 认证 


BlockToken 的 认证 是 在 BlockTokensecretManager 的 checkAccess 方 法 中 执行 的 ， 接 下 来 我 们 需要 找到 这 个 方法 的 调用 处 ， 答 案 在 DataXceiver 类 中 。DataXceiver 是 一 个 数据 处 理 中 心 ， 它 会 接收 各 
种 块 操作 命令 ， 然 后 执行 对 应 的 处 理 方法 。 而 在 readBlock、writeBlock 执 行 的 前 几 步 操作 中 ， 就 包含 了 BlockToken 的 认证 操作 。 以 readBlock 方 法 为 例 : 





public void readBlock (final ExtendedBlock block, 

final Token<BlockTokenIdentifier> blockToken, 

final String clientName, 

final long blockOffset, 

final long length, 

final boolean sendChecksum, 

final CachingStrategy cachingStrategy) throws IOException { 
previousOpClientName = clientName; 
long read = 0; 
updateCurrentThreadName ("Sending block " + block); 
OutputStream baseStream = getOutputSstream(); 
DataOutputStream out = getBufferedOoutputStream(); 
// 进行 Token READ 访 问 模式 的 验证 
checkAccess (out, true, block, blockToken, 

OP.READ BLOCK, BlockTokenIdentifier.AccessMode.READ); 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





checkAccess 方 法 的 代码 如 下 : 





Private void checkAccess (OutputStream out, final boolean reply, 
final ExtendedBlock blk, 
final Token<BlockTokenIdentifier> t, 
final Op op, 
final BlockTokenIdentifier.AccessMode mode) throws IOException { 
checkAndWaitForBP (blk); 
// 进行 是 否 已 启用 BlockToken 验 证 的 判断 
if (datanode.isBlockTokenEnabled) { 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Checking block access token for block '" + blk.getBlockId() 
+ "With mode '™" + mode + "'"); 
i 
try { 
// 进行 BlockToken 的 访问 验证 
datanode .blockPoolTokenSecretManager.checkAccess (t, null, blk, mode); 
} catch (InvalidToken e) { 
// 验证 异常 处 理 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 最 终 的 checkAceess 方 法 中 ， 进 行 多 指标 维度 的 信息 认证 : 





Public void checkAccess (Token<BlockTokenIdentifier> token, String userId, 
ExtendedBlock block, BlockTokenIdentifier.AccessMode mode) throws InvalidToken { 
BlockTokenIdentifier id = new BlockTokenIdentifier(); 


try { 
// 反 序 列 化 Token 
id.readFields (new DataInputStream (new BYyteArrayInputStream (token 
.getIdentifier()))); 
} catch (IOException e) { 
throw new InvalidToken( 
"Unable to de-serialize block token identifier for user=" + userId 
+ ", block=" + block + ", access mode=" + mode); 


} 

// 进行 相关 信息 的 验证 

checkAccess (id, userId, block, mode); 

// 进行 密码 的 验证 

if (!Arrays.equals (retrievePassword(id), token.getPassword())) { 
throw new InvalidToken ("Block token with " + id.toString() 


+ " doesn't have the Correct token password"); 





继续 进入 id、userld 等 相关 信息 的 认证 方法 : 





public void checkAccess (BlockTokenIdentifier id, String userId, 
ExtendedBlock block, BlockTokenIdentifier.AccessMode mode) throws InvalidToken { 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Checking access for user=" + UserId + ", block=" + block 
+ ", access mode=" + mode + " using " + id.tostring()); 


// 用 户 Igd 验 证 
if (userId != null && !userId.equals (id.getUserId())) { 
throw new InvalidToken ("Block token with " + id.tostring() 
+ " doesn't belong to user " + userId); 
人 
// BlockPoolId 验 证 
if (!id.getBlockPoolId() .equals (block.getBlockPoolId())) { 
throw new InvalidToken ("Block token with " + id.toString() 
+ " doesn't apply to block " + block) 7 


} 
// 块 Td 验 证 
if (id.getBlockId() != block.getBlockId()) { 
throw new InvalidToken ("Block token with " + id.toString() 
+ " doesn't apply to block " + block); 


// 过 期 验证 
if (isExpired(id.getExpiryDate())) { 
throw new InvalidToken ("Block token with " + id.toString() 
+ " is expired."); 


下 
// 访问 模式 验证 
if (!id.getAccessModes() .contains (mode)) { 
throw new InvalidToken ("Block token with " + id.toString() 
+ " doesn't have " + mode + " permission"); 





通过 上 述 过 程 的 分 析 ， 可 以 看 出 BlockToken 的 认证 是 非常 严格 的 ， 一 旦 Token 中 某 个 指标 信息 不 匹配 ， 马 上 会 抛 出 异常 ， 后 续 的 方法 也 随 之 无 法 继续 进行 。HDFS 将 BlockToken 认 证 处 理 放 在 
DataXceiver 中 ， 进 行 全 局 的 控制 ， 显 然 是 精密 思考 的 选择 。 图 2-19 是 BlockToken 认 证 的 流程 示意 图 。 








DataXceiver.checkAccess 


userld 是 否 相 等 ? 





BlockToken 认证 





blockPoolld 是 否 相等 ? 


blockld 是 否 相 等 ? 


是 否 包 含 AccessMode ? 


password 是 否 相 等 ? 











2-19 ”BlockToken 认 证 流程 








3.BlockToken 认 证 配置 


下 面 介绍 BlockToken 的 配置 控制 ， 配 置 项 名 称 如 下 : 





dfs.block.access.token.enable 




















该 配置 项 默认 不 开启 ， 就 是 false 状 态 。 如 果 我 们 出 了 
证 操作 ， 而 且 这 些 操作 在 每 次 的 块 操作 中 都 会 进行 。 
































2.5.2 ”HDFS 的 Sasl 认 证 


这 一 节 将 关注 点 移 向 HDFS 中 的 另外 一 套 认证 体系 : Sasl 认 证 。 说 起 Sasl， 它 不 是 HDFS 所 特有 的 ， 它 是 一 套 公开 的 认证 机 制 ， 全 称 是 Simple Authentication and Security Layer， 中 文 翻译 为 “ 简 重 
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证 与 安全 层 ”， 是 一 种 用 来 扩充 C/S 模 式 验证 能 力 的 机 制 。 











那么 HDFS 中 的 Sas 与 平常 我 们 所 说 的 Sasl 机 制 有 什么 不 同 呢 ? 笔者 个 人 认为 没有 本 质 的 区 别 ， 只 是 将 Sasl 认 证 体系 整合 进 了 HDFS 的 数据 读 写 流程 中 。 























所 以 如 果 你 之 前 了 解 过 Sasl, 或 者 
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这 套 体系 ， 可 能 后 面 的 内 容 会 比较 容易 理解 。 在 下 面 的 内 容 中 ， 主 要 选 出 了 Sas| 与 HDFS 结 合 的 部 分 进行 分 析 。 











四 














1.SaslClient 与 SaslServer 的 握手 








在 上 面 的 内 容 中 已 经 介绍 过 Sas| 是 C/S 模 式 的 认证 机 制 ， 所 以 自然 地 会 分 出 两 个 角色 : SaslClient 和 SaslServer。 在 每 次 的 数据 传输 中 ， 客 户 端 与 服务 端 都 会 进行 一 次 握手 (handshake) 。 比 如 在 
DataStreamer 的 transfer 方 法 中 : 














Private void transfer (final DatanodeInfo src, final DatanodeInfo[] targets, 
final StorageType[] targetStorageTypes, 
final Token<BlockTokenIdentifier> blockToken) 
throws IOException { 
// 传 输 副本 到 新 的 市 点 
Socket sock = null; 
DataOutputStream out = null; 
DataInputStream in = null; 
try { 
sock = createSocketForPipeline (src, 2, dfsClient); 
final long writeTimeout = dfsClient.getDatanodeWriteTimeout (2); 


// 数据 传输 超时 时 间 的 计算 ， 时 间 长 短 取决 于 传输 数据 包 的 大 小 

int multi = 2 + (int) (bytesSent /dfsClient.getConf () .getNritePacketSize ()) 
/ 200; 

final long readTimeout = dfsClient .getDatanodeReadTimeout (multi); 


OutputStream unbufOut = NetUtils.getOutputSstream(sock, writeTimeout); 
InPutStream unbufIn = NetUtils.getInputStream(sock, readTimeout); 
// SaslClient 与 服务 端 建立 一 次 握手 
IOStreamPair saslStreams = dfsClient.saslClient.socketSend (sock, 
unbufOout, unbufIn, dfsClient, blockToken, src); 
// 获取 结果 输入 流 和 输出 流 
unbufOut = saslStreams.out; 
unbufIn = saslStreams.in; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


数据 安全 性 的 考虑 ， 启 用 了 块 认证 的 功能 ， 需 要 注意 的 一 点 是 它 可 能 会 对 HDFS 的 块 读 写 性 能 造成 影响 。 因 为 里 面 有 一 些 反 序列 化 操作 和 很 多 的 认 





略 过 dfsClient.saslClient 的 中 间 处 理 方法 ， 进 入 最 终 的 握手 处 理 方法 : 





private IOStreamPair send(InetAddress adqr，OutputStream underlyingout, 
InputStream underlyingIn, DataEncryptionKey encryptionKey, 
Token<BlockTokenIdentifier> accessToken, DatanodeID datanodeId) 
throws IOException { 
// 如 果 加 密 key 不 为 空 ， 则 进行 加 密 握 手 方式 
if (encryptionKey != null) { 
LOG.debug ("SASL client doing encrypted handshake for addr = {}, " 
+ "datanodelId = {}", addr, datanodeId); 
return getEncryptedStreams (addr, underlyingOut, underlyingIn, 
encryptionKey); 
} else if (!UserGroupInformation.isSecurityEnabled()) { 
// 如 果 安 全 配置 没有 开启 ， 则 跳 过 握手 操作 
LOG.debug ("SASL client skipping handshake in unsecured configuration for " 
+ "addr = {}, datanodeId = {}", addr, datanodeId); 
return null; 
} else if (SecurityUtil.isPrivilegedPort (datanodeId.getXferPort())) { 
// 如 果 是 特权 端口 号 ， 也 不 做 处 理 
LOG.debug ( 
"SASL client skipping handshake in secured configuration with " 
+ "privileged port for addr = {}, datanodeId = {}", 
addr, datanodeId); 
return null; 
} else if (fallbackToSimpleAuth != null && fallbackToSimpleAuth.get()) { 
// 如 果 是 简单 认证 模式 ， 也 跳 过 握手 操作 


LOG.debug( 
"SASL client skipping handshake in secured configuration with " 
+ "unsecured cluster for addr = {}, datanodelId = {}", 


addr, datanodeId); 
return null; 
} else if (saslPropsResolver != null) { 
// 进行 普通 方式 的 握手 
LOG.debug( 
"SASL client doing general handshake for addr = {}, datanodeId = {}", 
addr, datanodeId); 
return getSaslStreams (addr, underlyingOut, underlyingIn, accessToken); 
} else { 
// 如 果 是 其 他 情况 ， 则 忽略 处 理 ， 返 回 nul1 
LOG.debug ("SASL client skipping handshake in secured configuration with " 
+ "no SASL protection configured for addr = {}, datanodeId = {}", 
addr, datanodeId); 
return null; 

















这 里 会 进行 多 重 因素 的 判断 ， 以 此 决定 用 何 种 握手 方式 。 大 体 分 为 以 下 几 种 : 




















-加密 key 不 为 空 ， 则 进行 加 密 握手 操作 。 
未 开启 安全 配置 模式 ， 不 进行 握手 操作 。 
. Sasl 相 关 配置 项 不 为 空 ， 进 行 普通 握手 操作 。 
. 如 果 是 特权 端口 号 ， 不 进行 握手 操作 。 
. 如 果 是 简单 认证 模式 ， 不 进行 握手 操作 。 


“ 其 他 情况 ， 同 样 不 进行 握手 操作 。 





所 以 真正 做 握手 操作 的 只 有 两 种 情况 ， 如 图 2-20 所 示 。 











加 密 握 手 操作 


Sasl 客户 端 普通 握手 操作 


不 进行 握手 操作 





图 2-20 HDFS 的 Sasl 握 手 方式 


如 果 我 们 什么 安全 配置 都 没有 开启 的 话 ， 也 就 是 延 用 默认 值 的 情况 ， 握 手 逻 辑 将 从 握手 处 理 方法 的 第 二 个 if 济 | 断 逻辑 中 跳 过 。 


2.DoSaslHandshake 


在 这 两 类 进入 真正 握手 阶段 的 方法 中 ， 会 提前 一 步 进 行 用 户 、 密 码 的 构造 过 程 。 











首先 是 加 密 握手 阶段 的 构造 过 程 : 

















private IOStreamPair getEncryptedStreams (InetAddress agdr, 
OutputStream underlyingOut, 
InputStream underlyingIn, DataEncryptionKey encryptionKey) 
throws IOException { 
Map<String, String> saslProps = createSaslPropertiesForEncryption( 
encryptionKey.encryptionAlgorithm); 


LOG.debug ("Client using encryption algorithm {}", 
encryptionKey.encryptionAlgorithm); 

// 用 encryptionKey 构 造 用 户 名 、 密 码 

String userName = getUserNameFromEncryptionKkey (encryptionKey); 

char[] password = encryptionKeyToPassword (encryptionKey.encryptionKey); 

// 利用 用 户 名 、 密 码 构造 回调 处 理 对 象 

CallbackHandler callbackHandler = new SaslClientCallbackHandler (userName, 
password); 

// 执行 具体 的 sas1 握 手 过 程 

return doSaslHandshake (addr, underlyingOut, underlyingIn, userName, 
saslProps, callbackHandler); 





第 二 个 是 普通 方式 握手 的 构造 过 程 : 





private IOStreamPair getSaslStreams (InetAddress addr, 
OutputStream underlyingOut, InputStream underlyingIn, 
Token<BlockTokenIdentifier> accessToken) 
throws IOException { 
Map<String, String> saslProps = saslPropsResolver.getClientProperties (addr); 
// 用 BlockToken 构 造 用户 名 、 密 人 码 
String userName = buildUserName (accessToken); 
char[] password = buildClientPassword (accessToken); 
//_ 利 用 用 户 名 、 密 码 构造 回调 处 理 对 象 
CallbackHandler callbackHandler = new SaslClientCallbackHandler (userName, 
assword); 
// 执行 具体 的 sas1 握 手 过 程 
return doSaslHandshake (addr, underlyingOut, underlyingIn, userName, 
saslProps, callbackHandler); 





上 述 两 个 过 程 中 有 共同 的 细节 处 理 操 作 : 生成 的 用 户 名 、 密 码 都 被 Base64 编 码 处 理 过 。 比 如 其 中 的 一 个 例子 : 





public static char[] encryptionKeyToPassword (byte[] encryptionKey) { 
return new String (Base64.encodeBase64 (encryptionKey, false), Charsets.UTF 8) 
.toCharArray (); 





Base64 编 码 的 处 理 可 以 防止 明文 的 暴露 。 经 过 以 上 处 理 之 后 ， 最 终 会 执行 真正 的 握手 阶段 ， 也 就 是 Sasl 的 认证 阶段 ， 客 户 端 与 服务 端 将 会 进行 身份 信息 的 交换 认证 。 


首先 由 SasilClient 端 发 起 ， 执 行 代码 如 下 : 








private IOStreamPair doSaslHandshake (InetAddress addr, 
OutputStream underlyingOut, InputStream underlyingIn, String userName, 
Map<String, String> saslProps, 
CallbackHandler callbackHandler) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


try { 
// 初始 握手 阶段 . 
sendSaslMessage (out, new byte[0]); 
// 下 面 进行 客户 端 询问 、 回 复 操 
// step 1 
byte[] remoteResponse = readSaslMessage (in); 
byte[] localResponse = sasl.evaluateChallengeOrResponse (remoteResponse); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
sendSaslMessageAndNegotiationCipherOptions (out, localResponse, 
cipherOptions); 


// Step 2 (client-side only) 

SaslResponseWithNegotiatedCipherOption response = 
readSaslMessageAndNegotiatedCipherOption (in); 

localResponse = sasl.evaluateChallengeOrResponse (response.payload); 

assert localResponse == null; 


// Sas1 担 手 完 成 


checkSaslComplete (sasl, saslProps); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 用 cipher 参 数 构造 stream 数 据 流 
return cipherOption != null ? createStreamPair( 
conf, cipherOption, underlyingOut, underlyingIn, false) 
sasl.createstreamPair (out, in); 
} catch (IOException ioe) { 
sendGenericSaslErrorMessage (out, ioe.getMessage()); 
throw ioe; 
} 
} 





然后 是 对 应 的 SaslServer 处 理 回应 操作 : 





private IOStreamPair doSaslHandshake (Peer peer, OutputStream underlyingout, 
InputStream underlyingIn, Map<String, String> saslProps, 
CallbackHandler callbackHandler) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


try { 
// 下 面 进行 服务 端的 询问 、 回 复 操作 
// step 1 
byte[] remoteResponse = readSaslMessage (in); 
byte[] localResponse = sasl.evaluateChallengeOrResponse (remoteResponse); 
sendSaslMessage (out, localResponse); 





本 











// step 2 (server-side only) 
List<CipherOption> cipherOptions = Lists.newArrayList (); 
// 读 取 sasl 信 息 并 生成 回复 
remoteResponse = readSaslMessageAndNegotiationCipherOptions( 
in, cipherOptions); 
localResponse = sasl.evaluateChallengeOrResponse (remoteResponse); 


// Sas] 握 手 完 成 
checkSaslComplete (sasl, saslProps); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 用 cipher 参 数 构造 stream 数 据 流 加 
return cipherOption != null ? createStreamPaiz( 
dnConf.getConf (), cipherOption, underlyingOut, underlyingIn, true) 
sasl.createSstreamPair (out, in); 
catch (IOException ioe) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 














在 握手 操作 完成 之 后 ， 将 会 得 到 一 个 新 的 输入 输出 流 对 象 。 如 果 我 们 没有 配置 cipher option 加 密 参 数 ， 将 会 默认 使 用 Sasllnputstream 和 SaslOutputstream。 此 部 分 的 Sasl 机 制 执行 逻辑 与 平常 我 们 所 
说 的 Sas| 基 本 一 致 。 图 2-21 是 对 应 的 流程 图 。 
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SaslOutputStream 
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创建 数据 流 


checkSaslComplete 





图 2-21 HDFS 的 Sasl 握 手 过 程 


大 致 总 结 一 下 图 2-21 中 doSaslHandshake 所 示 的 过 程 : 





1) 首先 客户 端 发 送 初始 请 求 。 
2) 服务 端 收 到 请 求 ， 生 成 询问 ， 发 送 给 客户 端 。 


3) 客户 端 收 到 询问 ， 处 理 询问 ， 生 成 回复 ， 发 送 给 服务 端 。 








4) 服务 端 收 到 询问 回复 ， 验 证 回复 ， 验 证 通过 后 ， 再 给 客户 端 一 个 响应 回复 ， 进 行 确认 。 
5) 双方 都 确认 完毕 ， 握 手 结束 。 
当然 ， 在 握手 阶段 如 果 发 生 了 失败 或 异常 ， 同 样 会 导致 后 续 操 作 的 失败 。 
3.SaslinputStream 和 SaslOutputStream 的 “多 余 处 理 ” 
现在 又 有 一 个 问题 出 现 了 ， 全 新 的 输入 输出 流 对 象 SaslInputStream 和 SaslOutputStream， 与 正常 情况 的 输入 输出 流 对象 有 什么 不 同 呢 ? 


官方 源码 对 此 的 解释 如 下 : 





Read 读 方法 从 底层 输入 数据 流 读 入 的 数据 将 会 被 SaslServer 或 SaslClient 对 象 进行 额外 地 处 理 。 
也 就 是 说 ， 所 有 的 数据 读 写 操作 需要 被 SasiClient 或 者 SaslServer 进 行 额外 地 处 理 。 从 源码 中 ， 我 们 也 可 以 找到 这 里 所 指 的 “额外 处 理 ” 部 分 的 代码 。 


首先 是 SalsOutputStream 写 数据 时 的 处 理 : 








public void write (byte[] inBuf, int off, int len) throws IOException { 
if (!useWrap) { 
outStream.write (inBuf, off, len); 
return; 


* 
try { 
// 此 处 将 会 进行 额外 的 包装 处 理 


if (saslServer != null) { 

saslToken = saslServer.wrap (inBuf, off, len); 
} else { 

saslToken = saslClient .wrap (inBuf, off, len); 


} catch (SaslException se) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


然后 是 SalsInputStream 读 数据 时 的 处 理 : 





Private int readMoreData() throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


try { 
// 此 处 进行 解 包装 处 理 


if (saslServer != null) 1{ 
obuffer = saslServer.unwrap (saslToken, 0, saslToken.length); 
} else { 


obuffer = saslClient.unwrap (saslToken, 0, saslToken.length); 


} catch (SaslException se) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





从 上 述 方法 的 执行 过 程 来 看 ， 这 恰好 是 一 次 包装 、 解 包装 的 过 程 ， 并 不 是 加 、 解 密 的 过 程 。 在 jdk 的 SaslServer 类 中 对 wrap 操作 方法 的 声明 解释 为 : “此 方法 的 结果 会 组 成 Sas| 缓 冲 区 的 内 容 (在 RFC 
2222 中 定义 ) ， 并 且 不 包含 表示 长 度 的 4 个 八 位 组 的 前 景 字段 。” 这 里 可 以 理解 为 wrap 方法 将 会 对 输入 内 容 进 行 重新 组 织 保存 。 


























当然 如 果 我 们 什么 安全 配置 都 没 开启 的 话 ， 这 些 过 程 都 不 会 发 生 ， 还 是 会 按照 原来 普通 的 输入 、 输 出 流 的 方式 进行 数据 读 写 的 处 理 。 
2.5.3 ”BlockToken 认 证 与 HDFS 的 Sasl 认 证 对 比 
以 上 内 容 对 HDFS 的 Sasl 只 是 讲 了 个 大 概 ， 内 部 的 诸多 细节 还 是 很 多 的 ， 有 兴趣 的 同学 可 以 自行 研究 。 下 面 对 本 节 所 述 的 两 个 认证 体系 做 一 下 对 比 。 
共同 点 : 
“ 没有 空间 局 部 的 限制 ， 都 是 数据 全 局 的 认证 。 


“ 都 会 对 数据 读 写 效率 造成 一 定 程度 的 影响 。 


“ 认证 维度 不 同 。BlockToken 认 证 的 粒度 较 细 ， 是 针对 块 级 别 的 认证 ， 会 对 每 次 的 块 操作 做 认证 。Sasl 则 是 针对 每 次 数据 传输 操作 做 认证 。 


“ 复杂 性 不 同 。BlockToken 的 认证 过 程 相 对 简单 、 清 晰 。 而 Sasl 认 证 体系 则 复杂 一 些 ， 会 经 过 握手 阶段 ， 而 且 中 间 还 可 以 配置 相关 的 认证 防护 级 别 (Qop) 的 参数 。 论 完整 度 而 言 ，Sasl 比 BlockToken 更 加 
完整 化 、 体 系 化 一 些 。 


2.6 HDFS 内 部 的 磁盘 目录 服务 


在 HDFS 中 ， 集 群 的 数据 分 散 地 存储 在 各 个 节点 的 磁盘 上 。 成 干 上 万 个 文件 、 成 干 上 万 个 磁盘 ， 在 某 些 时 刻 会 很 容易 发 生 数 据 的 损坏 或 节点 磁盘 的 损坏 。 随 着 集群 规模 的 扩大 ， 这 种 事件 发 生 的 概率 将 会 
越 来 越 高 。 对 此 ，HDFS 在 DataNode 所 在 的 节点 中 启动 了 多 种 磁盘 目录 的 检测 服务 ， 来 保证 数据 的 完整 性 与 一 致 性 。 这 些 服务 程序 并 不 都 是 周期 性 的 服务 ， 而 是 根据 其 使 用 的 场景 做 了 具体 的 设计 。 本 节 将 
主要 介绍 目前 现 有 的 三 大 磁盘 检测 服务 : DiskChecker、DirectoryScanner 和 VolumeScanne。 对 于 每 种 磁盘 检测 服务 ， 我 们 将 从 使 用 场景 以 及 作用 原理 两 方面 进行 详细 讲述 。 













































































2.6.1 _HDFS 的 三 大 磁盘 目录 检测 扫描 服务 








I 


如 前 面 所 提 到 的 ，HDFS 为 了 保证 DataNode 上 数据 的 完整 性 与 一 致 性 ， 在 DataNode 上 启动 了 三 大 磁盘 目录 扫描 服务 : DiskChecker、DirectoryScanner 和 VolumeScanner。 以 下 是 三 大 服务 的 简 
介绍 : 




















“ DiskChecker: 坏 盘 检测 服务 。 检 测 的 级 别 是 每 个 磁盘 ， 检 测 的 对 象 是 FsVolume，FsVolume 对 应 一 个 存储 数据 的 磁盘 。 通 过 检测 文件 目录 的 访问 权限 以 及 目录 是 否 可 创建 来 判断 目录 所 属 磁 瘟 的 好 坏 ， 
如 果 是 坏 盘 ， 则 此 块 盘 将 会 被 移 除 ， 上 面 的 所 有 块 都 将 被 重新 复制 。 


“ DirectoryScanner: 目录 扫描 服务 ， 对 每 块 盘 上 的 目录 做 扫描 ， 使 之 与 内 存 中 维护 的 块 信息 同步 。 比 如 存储 在 磁盘 上 的 块 已 经 没有 了 ， 则 内 存 中 的 块 信息 也 应 该 被 移 除 。 


* VolumeScanner: 磁盘 目录 扫描 服务 。 从 名 称 上 来 看 ，VolumeScanner 与 DirectoryScanner 比 较 类 似 , 但 是 VolumeScanner 才 是 真正 意义 上 的 块 检 查 服务 。 它 会 对 已 发 现 的 “可 疑 块 ”做 检查 ， 判 断 此 块 是 否 
为 损坏 块 ， 如 果 是 ， 则 会 将 其 汇报 给 NameNode。 


以 上 三 大 磁盘 目录 服务 对 于 DataNode 来 说 ， 起 到 了 保驾 护 航 的 作用 ， 下 面 在 原理 和 细节 上 对 以 上 三 种 服务 进行 进一步 分 析 。 





2.6.2 ”DiskChecker: 坏 盘 检测 服务 














这 里 的 坏 盘 指 的 是 坏 的 磁盘 。 为 什么 要 对 坏 盘 做 监控 呢 ? 一 般 用 户 使 用 HDFS 的 时 候 ， 会 将 每 个 DataNode 数 据 目录 所 在 的 本 地 目录 挂 载 到 某 块 独立 的 盘 上 ， 以 此 来 完全 利用 节点 的 存储 空间 。 所 以 如 果 
某 块 盘 突然 发 生 了 硬件 故障 导致 写 文件 失败 ， 这 块 盘 将 会 被 HDFS 检 测 出 来 ， 并 加 入 到 坏 盘 列 表 ， 其 上 的 数据 也 将 被 完全 拷贝 一 份 。 也 就 是 说 ，DataNode 从 此 刻 开始 就 完全 不 会 用 这 块 盘 了 。 由 此 可 
见 ，HDFS 对 于 坏 盘 的 检测 还 是 非常 看 重 的 ， 毕 竟 谁 也 不 想 把 数据 放 在 坏 了 的 磁盘 上 吧 。 



























































DiskChecker 服 务 并 不 是 一 个 周期 性 的 定时 任务 ， 它 只 会 在 可 能 有 坏 盘 出 现 的 场景 中 被 启动 ， 然 后 执行 。 在 这 点 上 ， 如 果 你 没有 仔细 研究 过 它 的 原理 ， 可 能 会 很 容易 被 它 的 名 称 所 误解 。 


1.DiskChecker 何 时 被 调用 


首先 ， 要 找到 DiskChecker 在 哪里 被 真正 执行 ， 答 案 在 DataNode 类 中 。 








// 启动 磁盘 错误 检查 线程 方法 
private void startCheckDiskErrorThread() { 
checkDiskErrorThread = new Thread (new Runnable() { 
QOverride 
public void run() { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 
] 7 





从 上 面 的 代码 可 以 看 出 ，DiskChecker 操 作 是 被 包装 在 一 个 线程 当中 。 然 后 我 们 只 要 继续 寻找 到 st 
的 方法 : 














artCheckDiskErrorThread 的 调 








方 ， 就 可 以 知道 哪里 会 调 








到 磁盘 检测 服务 了 。 在 这 里 可 以 找到 下 面 





Public void checkDiskErrorAsync() { 
synchronized (checkDiskErrorMutex) 
checkDiskErrorFlag = true; 
// 如 果 磁 盘 检 测 服务 为 空 
if (checkDiskErrorThread == null) 
// 新 建 磁盘 检测 服务 对 象 实 例 
startCheckDiskErrorThread (); 
// 启动 此 服务 ， 进 行 磁盘 的 检测 
checkDiskErrorThread.start (); 
LOG.info("Starting CheckDiskError Thread"); 


{ 


{ 





checkDiskErrorAsync 方 法 就 是 DataNode 对 外 提供 的 磁盘 检测 方法 。checkDiskErrorAsync 方 法 有 多 处 调 F 
































的 场景 ， 这 里 以 其 中 的 一 处 调 有 








为 例 : 











private int receivePacket () throws IOException { 
// 读 取 下 一 个 数据 包 


packetReceiver.receiveNextPacket (in); 


PacketHeader header packetReceiver .getHeader (); 
if (LOG.isDebugEnabled()){ 
LOG.debug ("Receiving one packet for block " + block + 
": "+ header); 
} 
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final boolean shouldNotWriteChecksum 
&& Streams .isTransientStorage () 7 
try { 


checksumReceivedLen 
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} catch (IOException iex) { 
// 写 数据 时 发 生 IO 异常 则 启动 一 次 磁盘 错误 检查 
datanode.checkDiskErrorAsync (); 
throw iex; 
} 





在 BlockReceiver 的 receivePacket 方 法 的 10 异常 处 理 中 ， 启 动 了 坏 盘 检测 。 类 似 的 还 有 其 他 调 











用 


景 ， 唯 一 不 同 的 场景 是 FsDatasetlImpl 的 validateBlockFile 方 法 ， 相 关 代 码 如 下 : 





File validateBlockFile (String bpid, long blockId) 
final File f; 
synchronized(this) { 
£f = getFile (bpid, blockId, false); 


{ 


if(f != null ) { 
if (f.exists()) 
return f; 
// 如 果 文 件 存 在 ， 但 是 实际 文件 并 不 存在 ， 则 有 可 能 磁盘 损坏 
datanode.checkDiskErrorAsync (); 





下 


if (LOG.isDebugEnabled()) { 
LOG.debug ("blockId=" + blockId + ", 
} 


return null; 


f=" + f£); 








所 以 综合 以 上 情况 ，DiskChecker 的 上 游 调用 流程 可 以 参考 








2-22。 





IOEXxception Wellets ts silole al[> 


checkDiskErrorAsync 


startCheckDiskErrorThread 


checkDIsSKError 


FsDatasetSpi.checkDataDir 














2-22 ”DiskChecker 上 游 调用 





2.DiskChecker 坏 盘 检测 原理 
坏 盘 检测 的 上 游 调 用 已 经 被 我 们 理 清 了 ， 但 是 它 内 部 的 执行 细节 是 怎样 的 呢 ? 在 何 种 情况 下 ，DiskChecker 才 会 把 一 块 盘 视 作 坏 盘 呢 ? 


这 里 进入 checkDataDir 方 法 : 





public Set<File> checkDataDir() { 
return volumes.checkDirs () 7 
} 





进一步 查看 checkDirs 方 法 实现 : 





Set<File> checkDirs() { 
Synchronized (checkDirsMutex) { 
Set<File> failedVols = null; 


// 获取 当前 所 有 的 volume，volume 对 应 的 是 存储 此 volume 的 盘 

final List<FsVolumeImpl> volumeList = getVolumes (); 

// 遍历 每 个 volume 

for (Iterator<FsVolumeImpl> i = volumeList.iterator(); i.hasNext(); ) { 
final FsVolumeImpl fsv = i.next(); 


try (FsVolumeReference ref = fsv.obtainReference()) { 
// 对 此 volume 进 行 检测 
fsv.checkDirs () 7 
} catch (DiskErrorException e) { 
// 如 果 在 此 期 间 发 生 DiskError 异 常 ， 则 此 块 将 被 移入 到 坏 盘 中 
FsDatasetImpl .LOG.warn ("Removing failed volume "+ fsv + ": 
if (failedVols == null) { 
failedVols = new HashSet<>(1); 
} 
failedVols.add (new File (fsv.getBasePath () ) .getAbsoluterFile()); 
addVolumeFailureInfo (fsv); 
// 在 DataNode 中 将 此 坏 盘 进行 移 除 ， 这 块 盘 将 不 会 有 新 的 数据 写 入 


removeVolume (fsv); 


, e); 
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} catch (ClosedChannelException e) { 
FsDatasetImpl .LOG.debug ("Caught exception when obtaining " + 
"reference count on closed volume", e); 
} catch (IOException e) { 
FsDatasetImpl .LOG.error ("Unexpected IOException", e); 
} 
} 
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return failedVols; 
$ 
} 











继续 进入 fsv.checkDirs 的 调 











void checkDirs () throws DiskErrorException { 
// TODO:FEDERATION valid synchronization 
// 这 里 对 存在 于 每 个 volume 上 的 不 同 的 BlockPool 存 储 目录 做 检查 
for (BlockPoolSlice s : bpSlices.values()) { 
s.checkDirs () 7 
} 








之 前 的 章节 中 已 经 提 到 过 ，HDFS 是 可 以 拥有 多 个 BlockPool 的 ， 这 些 不 同 的 BlockPool 在 每 个 盘 上 的 存储 是 以 BP 打头 的 
NameNode 的 ip 地 址 : 

















录 做 区 分 的 ， 类 似 格 式 如 下 ， 其 中 xx.xx.xx.xx 代 表 的 是 当时 做 格式 化 操作 的 








BP-805037254-xx.xx.xx.xx-1460537955319 

















而 其 对 应 的 相关 类 是 BlockPoolSlice， 意 为 每 个 BlockPool 在 每 块 目录 盘 上 的 分 片 。 





新 [ 


回 














到 刚才 的 检查 方法 s.checkDirs， 











执行 逻辑 如 下 : 








void checkDirs () throws DiskErrorException { 
// 对 finalized 目 录 做 递归 检查 
DiskChecker .checkDirs (finalizedDir); 
// 对 tmp 目 录 做 检查 
DiskChecker.checkDir (tmpDir); 
// 对 rbw 目 录 做 检查 
DiskChecker.checkDir (rbwDir); 














明白 以 上 3 类 目录 的 





为 什么 检查 以 上 3 大 类 的 目录 呢 ? 那 就 途 关系 了 : 














“ finalizedDir 目 录 ， 已 经 完成 后 的 块 文件 存储 目录 ， 层 级 不 止 一 层 ， 子 目录 下 还 存在 子 目 录 ， 所 以 在 此 处 需要 递归 地 检查 。 


“ tmpDit 临 时 目录 ， 存 储 临 时 副本 的 目录 。 
“ tbwDir 目 录 ， 正 在 写 操 作 的 文件 会 存放 于 此 目录 ， 写 完成 之 后 ， 会 被 移入 到 finalizedDir 目 录 中 。 


下 面 是 DiskCheckercheckDir 方 法 的 代码 ， 其 中 的 逻辑 就 是 坏 盘 检测 的 核心 逻辑 了 : 





public static void checkDir (File dir) throws DiskErrorException { 
// 尝试 创建 目录 的 检查 
if (!mkdirsWithExistsCheck(dir)) { 
throw new DiskErrorException("Cannot create directory: 
+ dir.toString ()); 


于 
// 文件 目录 的 访问 权限 的 检查 
checkDirAccess (dir); 

} 





在 上 面 的 检查 逻辑 中 ， 包 括 两 大 部 分 的 检测 。 


第 一 步 ， 创 建 目录 的 检测 。 在 这 里 会 通过 执行 mkdir 的 方法 来 判断 是 否 能 够 创建 出 目录 。 





Public static boolean mkdirsWithExistsCheck (File dir) { 
// 尝试 创建 目录 ， 并 检测 目录 是 否 存在 
if (dir.mkdir() || dir.exists()) { 
return true; 


} 
// 如 果 检 测 失败 ， 则 往 上 一 层 检测 ， 如 果 上 一 层 的 父 目 录 已 不 存在 ， 则 直接 返回 false 








File canonDir = null; 
try { 
canonDir = dir.getCanonicalrFile(); 


} catch (IOException e) { 
return false; 
} 
String Parent = canonDir.getParent (); 
return (parent != null) && 
(mkdirsWithExistsCheck (new File(parent)) && 


(canonDir.mkdir() || canonDir.exists())); 





第 二 步 ， 访 问 权限 的 检测 。 检 测 的 逻辑 是 判断 目录 的 是 否 能 够 进行 读 、 写 和 执行 。 





private static void checkAccessByFileMethods (File dir) 
throws DiskErrorException { 
// 对 目录 是 否 可 读 做 检查 
if (!FileUtil.canRead(dir)) { 
throw new DiskErrorException("Directory is not readable: 
+ dir.toString ()); 


} 
// 对 目录 是 否 可 写 做 检查 
if (!FileUtil.canWrite(dir)) { 
throw new DiskErrorException("Directory is not writable: 
+ dir.toSstring()); 





} 
// 对 目录 是 否 可 执行 做 检查 


if (!FileUtil.canExecute(dir)) { 
throw new DiskErrorException("Directory is not executable: 
+ dir.toSstring()); 











坏 盘 被 DiskChecker 检 测 出 来 之 后 ， 会 在 NameNode 的 50070 端 








中 显示 出 来 ， 集 群 管理 人 员 看 到 了 可 以 做 后 续 的 处 理工 作 。 


当 











3.DiskChecker 注 意 点 
笔者 在 工作 中 发 现 DiskChecker 在 使 用 上 存在 几 点 需要 注意 的 地 方 ， 稍 不 注意 ， 这 些 点 会 给 你 埋 下 不 少 坑 。 
Ot 


“ 坏 盘 检 测 的 误 判 。 磁 盘 损坏 毕竟 是 一 个 硬件 问题 ， 而 DiskChecker 是 在 软件 层面 做 的 检查 。 一 旦 我 们 有 不 符合 DiskChecker 检 测 逻 辑 的 行为 就 会 导致 坏 盘 出 现 。 也 就 是 说 ， 我 们 有 时 候 会 人 工地 时 致 坏 盘 
的 出 现 ， 比 如 在 之 前 的 finalizedDir 目 录 中 ， 我 们 删除 了 大 部 分 的 目录 ， 那么 过 了 不 久之 后 ， 这 块 盘 也 会 被 检测 为 坏 盘 ， 但 是 实质 上 这 块 盘 并 没有 故障 。 


:大量 的 坏 意 导 致 DataNode 启 动 的 失败 。DataNode 对 坏 盘 有 一 定 的 容忍 数量 ， 如 果 在 DataNode 启 动 的 时 候 发 现 坏 盘 的 数量 已 超过 可 容忍 数量 的 时 候 ， 会 导致 启动 的 失败 。 可 容忍 坏 盘 数量 取决 于 配置 项 


dfs.datanode.failed.volumes.tolerated。 


2.6.3 DirectoryScanner: 目录 扫描 服务 





























粗 看 DirectoryScanner 这 个 名 称 ， 你 可 能 看 不 出 这 个 服务 真正 的 用 途 ， 从 源码 的 注释 中 我 们 可 以 获取 此 服务 用 途 的 详细 解释 : 





* 阶段 性 扫描 数据 存储 目录 上 的 块 文件 以 及 块 元 数据 信息 文件 ， 
站 与 DataNode 内 存 中 所 维护 的 数据 趋向 一 致 。 
@InterfaceAudience.Private 
public class DirectoryScanner implements Runnable { 








大 意 为 阶段 性 扫描 块 以 及 块 的 元 数据 文件 ， 使 之 与 DataNode 内 存 中 维护 的 数据 趋向 一 致 





DirectoryScanner 内 部 定义 了 两 类 线程 池 以 及 扫描 间隔 时 间 : 





public class DirectoryScanner implements Runnable { 
Private static final Log LOG = LogFactory.getLog (DirectoryScanner.class); 


private final FsDatasetSpi<?> dataset; 

// 报告 产生 线程 池 

private final ExecutorService reportCompileThreadPool; 

// 主线 程 池 

private final ScheduledExecutorService masterThread; 

// 扫描 间隔 时 间 

private final long scanPeriodMsecs; 
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DirectoryScanner 会 被 提交 到 masterThread 主 线程 池上 ， 然 后 定期 执行 ， 从 而 做 到 周期 性 执行 








void start() { 
shouldRun = true; 
long offset = DFSUtil.getRandom() .nextInt ((int) (scanPeriodMsecs/1000L)) * 1000L; //msec 
long firstScanTime = Time.now() + offset; 
LOG.info("Periodic Directory Tree Verification scan starting at " 
+ firstScanTime + " with interval " + scanPeriodMsecs); 
// 将 DirectoryScanner 加 入 主线 程 池 做 定期 地 执行 
masterThread.scheduleAtFixedRate (this, offset, scanPeriodMsecs, 
TimeUnit .MILLISECONDS); 





接着 进入 run 方 法 : 





QOverride 
public void run() { 
try { 
if (!shouldRun) 
// 停止 当前 服务 ， “如果 此 线程 已 名 经 被 外 界 标记 为 停止 状态 
LOG.warn ("this cycle terminating ;immediately because 'shouldRun' has been deactivated"); 
return; 


} 
// 执行 数据 同步 操作 


reconcile(); 


} catch (Exception e) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 
} 





继续 进入 reconcile 方 法 : 





// 同步 磁盘 和 内 存 中 的 块 数据 信息 
void reconcile () throws IOException 
// 扫描 内 存 中 的 块 信息 与 本 地 块 信息 ， 忠和 拓 信 息 的 diff 差 异 列表 
Scan () 7 
// 遍历 diff 信 息 列表 
for (Entry<String, LinkedList<ScanInfo>> entry : diffs.entrySet()) { 
String bpid = entry.getKey(); 
LinkedList<ScanInfo> diff = entry.getValue(); 


for (ScanInfo info : difF)y 4 
// 进行 相应 的 数据 更 新 操作 
dataset .checkAndUpdate (bpid, info.getBlockId(), info.getBlockFile(), 
info.getMetaFile(), info.getVolume()); 
} 
} 
if (!retainDiffs) clear(); 
} 








reconcile 数 据 的 同步 化 操作 会 进行 两 大 操作 : scan 和 checkAndUpdate 操 作 。scan 的 目的 在 于 获取 diff 差 异 列表 ，checkAndUpdate 才 是 使 数据 一 致 化 的 操作 。 


1.scan 生 成 diff 差 异 报告 








diff 差 异 报告 的 生成 需要 同时 获取 磁盘 上 的 块 信息 报告 和 内 存 中 的 块 信息 报告 ， 然 后 做 具体 维度 的 比较 ， 比 较 逻 辑 代码 如 下 : 





void Scan () { 
clear (); 
// 首先 获取 磁盘 上 的 块 报告 列表 
Map<String, ns diskReport = getDiskReport (); 


// 此 处 获取 FSDataset 锁 来 保证 能 够 同步 操作 块 的 映射 图 对 象 
Synchronized (dataset) { 
for (Entry<String，ScanInfo[]> entry : diskReport.entrySet () ) { 
String bpid = entry.getKey (); 
ScanInfo[] blockpoolReport = entry.getValue () 7 


Stats statsRecord = new Stats (bpid) 7 

stats.put (bpid, statsRecord); 

LinkedList<ScanInfo> diffRecord = new LinkedList<ScanInfo>(); 
// 加 入 BlockPool 对 应 的 初始 diff 记 录 

diffs.put (bpid, diffRecord); 


statsRecord.totalBlocks = blockpoolReport.length; 
// 获取 内 存 中 的 块 报告 信息 
List<FinalizedReplica> bl = dataset .getFinalizedBlocks (bpid); 
Dred ke} memReport = bl.toArray (new FinalizedReplical[lbl.size()]); 
// 对 内 存 报告 进行 排序 
Arrays.sort (memReport); 
// blockpoolReport 对 象 当 前 下 标 
int d= 0; 
// memReport 下 标 
int m= 0; 
while (m < memReport.length && d < blockpoolReport.length) { 
FinalizedReplica memBlock = memReport [ml]; 
7 info = blockpoolReport[d]; 
一 种 情况 ， 内 存 中 的 块 丢失 ， 而 磁盘 中 的 块 还 在 
4 em getBlockId() < memBlock.getBlockId()) { 
if (!dataset.isDeletingBlock (bpid, info.getBlockId())) { 
// 块 信息 在 内 存 中 丢失 ， 进 行 计数 的 累加 
statsRecord.missingMemoryBlocks++; 
addDifference (diffRecord, statsRecord, info); 
} 
d++t; 
continue; 


} 

// 第 二 种 情况 ， 磁 盘 中 的 块 丢失 ， 而 内 存 中 的 块 还 在 

if (info.getBlockId() > memBlock.getBlockId()) { 
addDifference (diffRecord, statsRecord, 

memBlock.getBlockId(), info.getVolume()); 

ImH+7 
continue; 

} 

if (info.getBlockFile() == null) 
// 第 三 种 情况 ， 块 元 数据 文件 存在 ， 请 内 文件 不 存在 
addDifference (diffRecord, statsRecord, info); 

} else if (info.getGenStamp() != memBlock.getGenerationstamp () 

|| info.getBlockFileLength() != memBlock.getNumBytes()) { 

// 第 四 种 情况 ， 块 元 数据 文件 中 的 版 本 值 或 文件 长 度 不 一 致 
statsRecord.mismatchBlockst++; 
adqdDifference (diffRecord, statsRecord, info); 

} else if (info.getBlockFile() .compareTo (memBlock.getBlockFile()) != 0) { 
// 第 五 种 情况 ， 块 文件 对 象 不 一 致 
statsRecord.duplicateBlocks++; 
addDifference (diffRecord, statsRecord, info); 

} 

d++; 


if (d < blockpoolReport.length) { i 
// 对 于 同一 块 ， 在 多 个 磁盘 上 可 能 会 存在 记录 信息 ， 此 处 无 须 增加 内 存 报告 的 下 标 
ScanInfo nextInfo = blockpoolReport [Math.min (dq，blockpoolReport.length - 1)]; 
if (nextInfo.getBlockId() != info.blockId) { 
++Hm; 
} 
} else { 
++m; 
} 
} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} //end for 
} //end synchronized 
} 





主要 针对 以 上 5 种 情况 的 差异 做 记录 ， 然 后 将 差异 记录 存 入 diffRecord 当 中 。 磁 盘 上 的 块 相关 文件 指 的 是 存放 在 每 个 数据 存储 目录 下 最 后 一 层 目 录 的 文件 。 在 subdir 目 录 下 ， 存 的 是 块 文件 以 及 对 应 的 元 
数据 文件 。 下 面 是 笔者 在 测试 集群 中 的 一 个 存储 目录 : 





$ 1s 
blk 1191182458 blk 1191182458 117448171.meta blk 1207959779 
blk 1207959779 _ 134228809.meta 





2.DataNode 的 更 新 操作 





以 上 操作 比较 完毕 之 后 ， 就 要 进行 相应 数据 的 更 新 趋同 操作 了 ， 也 就 是 下 面 的 checkAndUpdate 方 法 : 





for (ScanInfo info : diff) { 
dataset .checkAndUpdate (bpid, info.getBlockId(), info.getBlockrFile(), 
info.getMetaFile(), info.getVolume()); 





checkAndUpdate 中 的 逻辑 检查 比较 复杂 ， 笔 者 对 其 进行 了 部 分 省 略 : 





public void checkAndUpdate (String bpid, long blockId, File diskFile, 
File diskMetaFile, FsVolumeSpi vol) throws IOException { 
Block corruptBlock = null; 
ReplicaInfo memBlockInfo; 
synchronized (this) { 
memBlockInfo = volumeMap.get (bpid, blockId); 


if (memBlockInfo != null && memBlockInfo.getState () != ReplicaState.FINALIZED) { 
// 当前 块 处 于 未 最 终 确认 状态 ， 此 处 进行 返回 操作 
return; 


i 


final long diskGS = diskMetaFile != null && diskMetaFile.exists() ? 
Block.getGenerationStamp (diskMetaFile.getName ()) 
GenerationStamp .GRANDFATHER GENERATION STAMP; 


if (diskFile == null || 于 exists()) { 
if (memBlockInfo == null) 
// 块 文件 不 存在 ， 同 1 英信 息 在 内 在 中 也 不 存在 ， 如 果 此 时 块 元 数据 文件 存在 ， 则 进行 移 除 
if (diskMetaFile != null && qiskMetaFile.exists () 
&& diskMetaFile.delete()) { 
LOG.warn ("Deleted a metadata file without a block " 
+ diskMetaFile.getAbsolutePath ()); 





} 


return; 


} 
if (!memBlockInfo.getBlockFile() .exists()) { 


// 如 果 磁 盘 中 的 块 已 经 不 在 了 ， 但 是 内 存 中 的 块 还 在 的 话 ， 从 内 存 中 移 除 

VolLumeMap .remove (bpid, blockId); 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 
return; 


} 


if (memBlockInfo 2 
// 磁盘 中 的 块 存在 ， 而 内 存 中 的 块 不 存在 ， 则 加 入 块 到 内 存 中 的 volumeMap 对 象 中 
ReplicaInfo diskBlockInfo = new FinalizedReplica (blockId, 
diskFile.length(), diskGS, vol, diskFile.getParentFile()); 
volumeMap.add (bpid, diskBlockInfo); 
if (vol.isTransientStorage()) { 
ramDiskReplicaTracker.addReplica (bpid, blockId, (FsVolumeImpl) vol); 
} 
LOG.warn ("Added missing block to memory " + diskBlockInfo); 
return; 





} 


// 文件 块 的 比较 
File memFile = memBlockInfo.getBlockFile(); 
if (memFile.exists()) { 
if (memFile.compareTo(diskFile) != 0) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 
} else { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 


// 比较 版 本 号 值 
if (memBlockInfo.getGenerationStamp () != diskGS) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 


// 如 果 内 存 中 的 块 文件 信息 与 块 中 的 文件 信息 不 一 致 ， 则 以 块 文件 中 的 为 准 
if (memBlockInfo.getNumBytes() != memFile.length()) { 
// 更 新 文件 大 小 信息 
corruptBlock = new Block (memBlockInfo); 
LOG.warn ("Updating size of block " + blockId + " from " 
+ memBlockInfo.getNumBytes() + " to " + memFile.length()); 
memBlockInfo.setNumBytes (memFile.1length()); 


} 


} 
// 其 他 情况 将 被 视 为 坏 块 ， 并 发 送 给 NameNode 
if (corruptBlock != null) { 
LOG.warn ("Reporting the block " + corruptBlock 
+ " as corrupt due to length mismatch"); 
try { 
datanode.reportBadBlocks (new ExtendedBlock (bpid, corruptBlock)); 
} catch (IOException e) { 
LOG.warn ("Failed to repot bad block " + corruptBlock, e); 
} 
. 
} 








本 ”的 角色 ， 将 这 段 时 间 内 出 现 的 一 些 异 常 的 数据 处 理 掉 ， 维 护 内 存 中 的 数据 与 磁盘 上 块 数据 的 完 








DirectoryScanner 是 一 项 周期 性 的 服务 ， 默 认 间 隔 执行 时 间 6 小 时 。DirectoryScanner 像 是 一 个 “ 
整 性 与 一 致 性 。 此 过 程 流程 图 如 图 2-23 所 示 。 


























DataNode.initDirectoryScanner 


DirectoryScannerstart 


reconclle 








FsDatasetSpi.checkAndUpdate 











2-23 ”DirectoryScannet 运 行 流程 





2.6.4 VolumeScanner: 磁盘 目录 扫描 服务 


VolumeScanner 是 专门 针对 每 块 磁盘 做 块 扫描 的 服务 。 块 扫描 类 似 于 一 次 健康 状况 的 检查 。 每 个 VolumeScanner 有 属于 它 自己 的 独立 线程 ， 代 码 如 下 : 








/** 
* 每 个 VolumnScanner 扫 描 一 块 盘 ， 并 且 每 个 VolumScanner 有 其 独自 的 线程 ， 
* 它们 统一 被 DataNode 的 BlockScanner 对 象 所 管理 。 

.A 

public class VolumeScanner extends Thread 








如 上 面 注释 中 所 说 明 的 ，VolumeScanner 是 被 BlockScanner 所 管理 的 。 同 时 VolumeScanner 的 初始 化 也 是 在 BlockScanner 中 进行 的 。 在 BlockScanner 的 addVolumeScanner 中 会 进行 新 的 
VolumeScanner 创 建 与 启动 : 





public synchronized void addVolumeScanner (FsVolumeReference ref) { 
boolean success = false; 
try { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
LOG.debug ("Adding scanner for volume {} (StorageID {})", 
Volume .getBasePath () ， volume.getStorageID()); 
// 为 此 volume 所 代表 的 磁盘 新 建 VolumeScanner 对 象 
scanner = new VolumeScanner (conf, datanode, ref); 
// 启动 此 线程 
scanner.start (); 
// 加 入 到 VolumScanner 了 映射 图 中 
scanners.put (volume .getStorageID(), scanner); 
Success = true; 
} finally { 
if (!success) { 
// 如 果 之 前 创建 VolumeScanner 对 象 没有 成 功 ， 则 不 需要 此 引用 对 象 
// 将 其 清除 即 可 
IOUtils.cleanup (null, ref); 
} 
} 
} 




















下 面 直接 进入 VolumeScanner 的 run 方 法 : 





public void run() { 
// 记录 扫描 开始 的 时 间 
this.startMinute = 
TimeUnit .MINUTES .convert (Time .monotonicNow(), TimeUnit.MILLISECONDS); 
this.curMinute = startMinute; 
try { 
LOG.trace("{}: thread starting.", this); 
// 初始 化 处 理 类 
resultHandler. setup (this); 
try { 
long timeout = 0; 
while (true) { 
ExtendedBlock suspectBlock = null; 
// 获取 当前 对 象 的 对 象 锁 ， 以 此 保证 操作 可 疑 块 列 表 的 同步 性 
synchronized (this) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 获取 下 一 个 可 疑 块 
suspectBlock = popNextSuspectBlock (); 


} 
// 进行 可 疑 块 的 扫描 
timeout = runLoop (suspectBlock); 
} 
} catch (InterruptedException e) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








在 run 方 法 中 执行 的 逻辑 如 下 : 
1) 初始 化 块 处 理 类 。 
2) 循环 获取 下 一 个 可 疑 检查 块 。 


3) 检测 扫描 选 出 的 可 疑 块 。 








上 面 代 码 中 的 resultHandler 处 理 类 会 在 扫描 块 操 作 的 时 候 被 调用 。 这 里 的 while 循 环 是 块 扫描 的 主要 操作 ， 在 这 个 循环 中 ， 会 进行 可 疑 块 的 筛选 和 扫描 操作 。 下 面 先 来 看 popNextSuspectBlock 的 处 理 
逻辑 : 























private synchronized ExtendedBlock popNextSuspectBlock() { 
Iterator<ExtendedBlock> iter = suspectBlocks.iterator () 7 
if (!iter.hasNext()) { 
return null; 


} 

// 从 可 疑 块 列表 中 选 出 块 
ExtendedBlock block = iter.next (); 
iter.remove () 7 

return block; 





这 里 的 可 疑 块 是 从 suspectBlocks 块 列表 中 移出 的 ， 而 suspectBlocks 是 VolumeScanner 所 维护 的 可 疑 块 列表 : 





// 可 疑 块 列表 ，scanner 线 程 将 会 优先 扫描 这 些 块 
private final LinkedHashSet<ExtendedBlock> suspectBlocks = 
new LinkedHashSet<ExtendedBlock> (); 

















经 过 调用 发 现 ， 将 块 标记 为 “可 疑 块 ” 从 而 将 其 加 入 到 可 疑 块 列表 中 : 











public synchronized void markSuspectBlock (ExtendedBlock block) { 
if (stopping) { 
LOG.info("{}: Not scheduling suspect block {} for "+ 
"rescanning, because this volume scanner is stopping.", this, block); 
return; 
} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
if (suspectBlocks.contains (block)) { 
LOG.info("{}: suspect block {} is already queued for "+ 
"rescanning.", this, block); 
return; 


} 

// 如 果 可 疑 块 列表 中 不 存在 此 块 ， 则 加 入 列表 

suspectBlocks.add (block); 

recentSuspectBlocks.put (block, true); 

LOG.info("{}: Scheduling suspect block {} for rescanning.", this, block); 
notify(); // 唤醒 scanner 线 程 




















同样 我 们 需要 找到 markSuspectBlock 的 调用 场景 ， 如 下 : 








Private int sendPacket (ByteBuffer pkt, int maxChunks, OutputStream out, 
boolean transferTo, DataTransferThrottler throttler) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


int dataOff = checksumOff + checksumDataLen; 
if (!transferTo) { 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 


try { 
if (transferTo) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} catch (IOException e) { 2 
if (e instanceof SocketTimeoutException) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
datanode .metrics.incrSendDataPacketTimeout (); 
} else { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
/7 必 生 其 他 的 108xcept on 的 时 候 ， 标 交 让 代为 可 蜂 稀 
datanode .getBlockScanner () .markSuspectBlock( 
VolumeRef .getVolume () .getStorageID ()， 
block); 
datanode.metrics.incrSendDataPacketExceptionNum(); 
} 
throw ioeToSocketException (e); 
上 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
return dataLen; 


} 





在 BlockSender 的 sendPacket 读 数据 方法 中 ， 如 果 发 生 了 IO 异 常 ， 则 会 进行 可 疑 块 的 标记 。 这 个 与 DiskChecker 类 似 ， 都 是 在 异常 的 场景 中 进行 触发 处 理 。 可 疑 块 被 筛选 出 来 之 后 ,会 经 过 runLoop 方 
法 的 处 理 : 








Private long runLoop (ExtendedBlock suspectBlock) { 
long bytesScanned = -1; 
boolean scanError = false; 
ExtendedBlock block = null; 


try’ 
long monotonicMs = Time.monotonicNow(); 
expireOldScannedBytesRecords (monotonicMs); 


if (!calculateShouldqScan (volume.getStorageID(), conf.targetBytesPerSec, 
hr startMinute, curMinute)) { 
// 如 果 扫 描 块 的 带宽 速率 设置 得 太 小 导致 不 允许 进行 扫描 操作 ， 则 返回 需要 等 待 的 时 间 
return 30000L; 


} 
// 寻找 一 个 可 用 的 BlockPool 准 备 扫描 
if (suspectBlock != null) { 
// 如 果 当 前 可 疑 块 不 为 空 ， 则 设置 为 当前 扫描 的 块 
block = suspectBlock; 
} else { 
否则 从 BlockPool 中 选 出 一 个 待 扫描 的 块 
if ((curBlockIter == null) || curBlockIter.atEnd()) { 
// 如 果 当 前 BlockPool 已 经 扫描 到 头 了 ， 则 选取 下 一 个 BlockPool 
long timeout = findNextUsableBlockIter (); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 
try { 
// 获取 当前 BlockPool 中 的 下 一 个 待 扫描 块 
block = curBlockIter. De oR 
} catch (IOException e) 
// 选取 块 时 出 现 异常 ， 生生 党 信息 
LOG.warn("{}: nextBlock error on | }", this, curBlockIter); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
return OL; 


: 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 对 选 定好 的 块 ， 进 行 扫描 ， 同 时 传 入 带宽 速率 进行 限 流 
bytesScanned = scanBlock (block, conf.targetBytesPerSec); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





以 上 的 处 理 罗 辑 主 要 表达 了 两 个 意思 : 





1) 从 suspectBlock (可 疑 块 列表 ) 中 选 出 一 个 待 扫描 块 进行 扫描 。 














2) 如 果 suspectBlock 没 有 可 选 的 块 了 ， 则 从 BlockPool 中 进行 选取 ， 如 果 当 前 的 BlockPool 中 的 块 已 经 遍历 完毕 ， 则 选取 下 一 个 BlockPool， 继 续 遍 历 其 中 的 块 。 


选 定 块 后 ， 接 着 会 进行 scanBlock 方 法 : 





private long scanBlock (ExtendedBlock cblock, long bytesPerSec) { 
ExtendedBlock block = null; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
if (block == null) { i 
// 返回 - 二 到 沁 没 有 要 到 


return -1; 


} 
BlockSender blockSender = null; 
try { 
blockSender = new BlockSender (block, 0, -1, 
false, true, true, datanode, ee 
Cachingstrateg 人 
// 用 Tocksenderi 衣 家 的 训 宰 。 寺 时 修 闻 眼 流 损 作 
throttler.setBandwidth (bytesPerSec); 
long bytesRead = blockSender.sendBlock (nullStream, null, throttler); 
// 进行 结果 的 处 理 
resultHandler.handle (block, null); 
return bytesRead; 
} catch (IOException e) 
// 和 
resultHandler.handle (block, e); 
} finally { 
IOUtils.cleanup (null, blockSender); 
} 


return -1; 




















BlockSender 在 扫描 块 的 时 候 ， 特 意 对 


进行 了 限 流 ， 防 止 








对 DataNode 正 常 读 写 的 影响 。 在 resultHandler 的 handle 处 理 方法 中 ， 包 含 了 对 扫描 块 的 最 终 处 理 : 





public void handle (ExtendedBlock block, IOException e) { 
3 Volume = scanner.volume; 





// 如 果 没 有 发 生 IOException 异 常 ， 则 意味 着 块 是 正常 块 

if (e == null) { 
LOG.trace ("Successfully scanned {} on {}", block, volume.getBasePath()); 
return; 








// 如 果 块 不 存在 于 DataNode 上 ， 同 样 返 回 
if (!volume.getDataset () .contains (block)) { 
LOG.debug ("Volume {}: block {} is no longer in the dataset.", 
Volume .getBasePath(), block); 
return; 
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if (e instanceof FileNotFoundException ) { 
LOG.info("Volume {}: verification failed for {} because of " + 
"FileNotFoundException. This may be due to a race with write.", 
Volume .getBasePath(), block); 
return; 
} 
LOG.warn ("Reporting bad on {}", block, volume.getBasePath()); 
// 其 他 异常 情况 ， 则 EE 并 才 并 且 上 报 坏 块 
try { 
scanner .datanode. Rope tee EE 
} catch (IOException ie) 
// 汇报 坏 块 失败 的 时 候 ， 沿 样 打出 异常 信息 息 
LOG.warn ("Cannot report bad " + block.getBlockId(), e); 
} 
} 








resultHandler 的 核心 逻辑 是 根据 BlockSender 读 块 时 是 否 抛 出 IO 异常 来 作为 块 好 坏 的 评判 标准 。 以 上 处 理 逻 辑 流程 见 图 2-24。 




















以 上 就 是 HDFS 在 DataNode 中 所 启动 的 三 大 服务 ， 每 个 服务 都 有 特定 的 作用 。 熟 悉 了 解 了 这 些 服务 ， 将 会 使 我 们 对 DataNode 的 运行 以 及 故障 问题 排查 有 很 大 的 帮助 。 








VolumeScanner.run 


runLoop - ; popNextSuspectBlock 


可 疑 块 为 空 ? 


curBlocklter.nextBlock 


scanBlock 





图 2-24 VolumeScanner 运 行 过 程 


27 ”小结 











本 章 内 容 履 盖 的 范围 比较 广 ， 而 且 部 分 章节 的 内 容 可 能 会 比较 难 懂 ， 比 如 HDFS 的 快照 管理 ，HDFS 如 何 进行 缓存 块 的 管理 等 等 。 当 然 还 有 一 些 是 偏重 理解 性 的 内 容 ， 阅 读 完 本 章节 我 们 要 大 致 理解 
HDFS 内 部 的 Sasl 认 证 过 程 以 及 其 与 BlockToken 验 证 的 差别 所 在 ， 还 有 DataNode 内 部 的 数据 保护 服务 等 等 。 经 典 的 三 副本 策略 机 制 也 是 我 们 需要 了 解 的 内 容 ， 副 本 放置 位 置 的 选择 是 其 中 比较 重要 的 一 








第 3 章 ”HDFS 的 新 颖 功能 特性 


本 章 介绍 HDFS 中 的 一 些 “ 非 主流 ”的 功能 特性 ， 这 些 功 能 并 不 是 不 好 ， 而 是 说 它 很 少 被 人 用 到 ， 容 易 被 大 家 忽视 。 本 章 首先 介绍 HDFS 的 视图 文件 系统 ViewFileSystem。 谁 说 HDFS 上 的 路 径 是 一 成 不 
变 的 ?ViewFs 可 以 让 你 随意 变更 存储 的 路 径 名 称 。 其 次 介绍 WebHDFS，WebHDFS 的 出 现 可 以 使 得 用 户 使 用 HDFS 的 成 本 变 得 更 为 简单 。 第 三 介绍 HDFS 数 据 加 密 空间 Encryption zone， 在 加 密 空间 下 ， 
你 看 到 的 将 只 会 是 一 堆 加 密 的 数据 流 。 第 四 介绍 HDFS EC 纠 删 码 技术 ， 这 是 用 户 非常 期 待 的 一 个 特性 ， 它 能 够 解决 当下 由 于 三 副本 备份 策略 导致 的 存储 空间 浪费 的 问题 。 第 五 介绍 HDFS 对 象 存储 技术 
Ozone， 它 使 得 用 户 将 数据 存 入 到 HDFS 中 变 得 更 容易 。 












































3.1 ”HDFS 视 图 文件 系统 : ViewFileSystem 


HDFS 视 图 文件 系统 并 不 是 一 个 全 新 类 型 的 文件 系统 ， 正 如 它 的 名 称 所 描述 的 ， 它 只 是 一 个 “视图 ”。“ 视 图 ”的 意思 代表 它 只 是 在 表面 上 做 了 改变 的 文件 系统 ， 而 真实 指向 的 文件 系统 其 实 并 没有 发 生 
变化 。 进 一 步 来 说 ，HDFS 视 图 文件 系统 可 以 跨越 多 个 集群 ， 保 持 文件 系统 在 逻辑 上 的 一 致 性 。 视 图 文件 系统 在 HDFS 中 的 名 称 叫 作 ViewFileSystem， 简 写 为 ViewFs。 在 本 节 中 ， 我 们 将 主要 介绍 视图 文件 
系统 的 使 用 场景 、 实 现 原 理 和 配置 的 使 用 三 方面 内 容 。 






































为 了 突出 视图 文件 系统 的 作用 ， 这 里 先 来 讨论 一 下 传统 数据 合并 的 方案 。 在 数据 合并 中 ， 常 用 的 做 法 是 搬迁 数据 。 例 如 在 HDFS 中 ， 我 们 会 想到 用 DistCp 工 具 进 行 远 程 拷 贝 。 虽 然 DistCp 本 身 就 是 用 来 
这 种 事情 的 ， 但 是 随 着 数据 量规 模 的 升级 ， 会 有 以 下 问题 的 出 现 : 

















“ 拷贝 周期 太 长 ， 如 果 数 据 量 非常 大 ， 在 机 房 总 带宽 有 限 的 情况 下 ， 找 贝 的 时 间 将 会 非常 长 。 


“ 数据 在 拷贝 的 过 程 中 ， 一 定 会 有 原始 数据 的 变更 与 改动 ， 如 何 同步 这 些 数据 也 是 需要 考虑 的 方面 。 


3.1.1 ”ViewFileSystem: 视 图 文件 系统 


关于 ViewFileSystem 的 概念 ， 首 先 要 明白 一 个 核心 原则 : ViewFileSystem 不 是 一 个 新 的 文件 系统 ， 只 是 逻辑 上 的 一 个 视图 文件 系统 ， 在 逻辑 上 是 唯一 的 。 








这 句 话 怎么 理解 呢 ，ViewFileSystem 就 是 帮 大 家 做 了 一 件 事情 : 将 各 个 集群 的 真实 文件 路 径 与 ViewFileSystem 内 新 定义 的 路 径 进 行 关联 映射 。 


上 面 这 句 话 的 意思 就 好 比 文件 系统 中 挂 载 的 意思 。 进 一 步 地 说 ，ViewFileSystem 会 在 每 个 客户 端 中 维护 一 份 挂 载 关 系 表 ， 就 是 上 面 说 的 集群 物理 路 径 -> 视图 文件 系统 路 径 这 样 的 指向 关系 。 但 是 在 挂 载 
关系 表 中 ， 关 系 当然 不 止 一 个 ， 会 有 很 多 个 。 比 如 下 面 所 示 的 多 对 关系 : 








/user -> hdfs://nnl/containingUserDir/user 
/project/foo -> hdfs://nn2/projects/foo 
/project/bar -> hdfs://nn3/projects/bar 





前 面 是 ViewFileSystem 中 的 路 径 ， 后 者 才 是 代表 的 真正 集群 路 径 。 所 以 你 可 以 理解 为 ViewFileSystem 真 正 干 的 事情 是 路 径 的 路 由 解析 。 图 3-1 是 简单 的 原理 图 。 








ls -1 /projects/foo 






depend on 


/user -> hdfs://nni/containingUserDir/user 
/project/foo -> hdfs://nn2/projects/foo 


/project/bar -> hdfs://nn3/projects/bar 





ViewFileSystem 


resolve 


hdfs://nn2/prohects/foo 





图 3-1 ViewFileSystem 的 路 由 解析 
3.1.2 ”ViewFileSystem 内 部 实现 原理 


在 上 文中 我 们 已 经 基本 了 解 到 ViewFileSystem 的 作用 是 一 个 路 由 解析 的 角色 ， 真 实 的 请 求 处 理 还 是 在 各 自 真实 的 集群 上 。 这 小 节 探 讨 的 内 容 是 ViewFileSystem 内 部 是 如 何 实现 这 个 “路 由 解析 ”的 角 
色 。 


1. 目 录 挂 载 点 





因为 要 做 的 是 路 由 解析 ， 所 以 挂 载 点 的 设计 就 显得 非常 重要 了 。 下 面 来 看 ViewFileSsystem 中 对 挂 载 点 的 定义 : 








static public class MountPoint { 
// 源 路 径 
Private Path src; 
// 目录 指向 路 径 ， 也 就 是 真实 路 径 ， 可 以 为 多 个 
Private URI[] targets; 
MountPoint (Path srcPath, URI[] targetURIs) { 
src = srcPath; 
targets = targetURIs; 
} 
Path getSrc() { 
return src; 


} 
URI[] getTargets() { 
return targets; 
} 
} 





一 般 情况 下 ， 挂 载 节 点 是 一 对 一 的 。 但 是 如 果 存 在 不 同 集群 间 有 相同 名 称 目录 的 情况 ， 也 是 可 以 进行 一 对 多 的 ， 在 Hadoop 中 叫做 MergeCount， 不 过 这 个 功能 目前 尚未 完成 ， 还 在 开发 中 ， 相 关 
JIRA: HADOOP-8298 (ViewFs merge mounts) 。 


2. 挂 载 点 的 解析 与 存放 





在 ViewFileSystem 初 始 化 操作 中 ， 挂 载 点 的 解析 与 存放 是 其 中 一 个 关键 的 过 程 。 其 中 的 过 程 执行 是 在 下 面 这 个 变量 中 进行 的 : 





// 此 对 象 可 理解 挂 载 表 
InodeTree<FileSystem> fsState; 





进入 ViewFileSystem 的 初始 化 方法 : 





public void initialize (final URI theUri, final Configuration conf) 
throws IOException { 
super.initialize (theUri, conf); 


setConf I 
config = SE 
// 根据 配置 信息 ， 初 始 化 挂 载 表 实例 
final String authority = theUri .getAuthority (); 
try { 
myUri = new URI (FsConstants.VIEWFS SCHEME, authority, "/", null, null); 
// 传 入 conf 配 置信 息 进行 fsstate 初 始 化 “ 
fsState = new InodeTree<FileSystem> (conf, authority) { 
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然后 进入 InodeTree 的 构造 方法 中 : 





protected InodeTree (final Configuration config, final String viewName) 
throws UnsupportedFileSystemException, URISyntaxException, 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


final String mtPrefix = Constants.CONFIG VIEWFS PREFIX + "." + 
VName + "."™; 
final String linkPrefix = Constants.CONFIG VIEWFS LINK + "."; 
final String linkMergePrefix = Constants.CONFIG VIEWFS LINK MERGE + "."7 
boolean gotMountTableEntry = false; I. 2 
final UserGroupInformation ugi = UserGroupInformation.getCurrentUser (); 
for (Entry<String, String> si : config) { 
final String key = si.getKey(); 
// 判断 源 key 名 是 否 以 前 缀 fs.viewfs .mounttable 开 头 
if (key.startsWith (mtPrefix)) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 哮 权 目次 庙 射 的 黄 实 密 径 ， 可 能 为 多 个 ， 以 \, “ 隔 开 
final String target = si.getValue(); 
CreateLink (src, target, isMergeLink, ugi); 
} 
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真正 实现 挂 载 点 关系 的 存储 是 在 createLink 方 法 中 ， 代 码 如 下 : 





Private void createLink (final String src, final String target, 
final boolean isLinkMerge, final UserGroupInformation aUgi) 
throws URISyntaxException, IOException, 
FileAlreadyExistsException, UnsupportedFileSystemException { 
// 验证 源 路 径 是 否 为 有 效 的 路 径 
final Path srcPath = new Path (Src) 
if (!srcPath.isAbsoluteAndSchemeAuthorityNull()) { 
throw new IOException ("ViewFs:Non absolute mount name in config:" + src); 
} 


// 将 待 添加 的 路 径 按照 \V” 分 隔 符 进行 拆 分 

final String[] srcPaths = breakIntoPathComponents (src); 

// 设置 当前 节点 为 根 节点 

INodeDir<T> curInode = root; 
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注意 上 面 执行 的 最 后 一 行 代码 ， 出 现 了 INodeDir 类 ， 而 且 设置 了 当前 curlnode 为 根 节点 。 这 实际 上 是 非常 有 用 意 的 。INodeDir 类 的 定义 为 : 











// 此 类 代表 挂 载 表 中 的 一 个 挂 载 目 录 
static class INodeDir<T> extends INode<T> { 
// 孩子 节点 
final Map<String INode<T>> children = new HashMap<String, INode<T>>(); 
// 与 此 挂 载 目 录 相 关 的 文件 系统 
T InodeDirFs = null; 
boolean isRoot = false; 
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从 上 面 我 们 可 以 看 出 这 里 是 一 个 父亲 -孩子 的 关系 。 每 个 目录 会 有 对 应 自身 的 目标 文件 系统 ， 而 且 孩 子 可 能 还 是 INodeDir 或 是 INode 的 子 类 。 因 为 路 径 按照 符号 “/” 进 行 划分 ， 我 们 大 臻 可 以 推测 出 





ViewFilesystem 是 按照 树 型 结构 的 存放 方式 进行 挂 载 点 的 存储 的 。 


下 面 的 代码 基本 上 验证 了 上 面 的 猜想 ， 下 面 是 目录 树 的 查找 过 程 
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hel se 
// 忽略 第 一 个 空 字符 串 ， 遍 历 其 后 的 每 一 个 子 段 
for {i =,1}.1< srcPaths, lerngth=17 it+) 4 
// 获取 当前 的 子 段 字符 串 
final String iPath = srcPaths([il]; 
// 从 当前 的 目录 INode 中 进行 查找 
INode<T> nextInode = curInode.resolveInternal (iPath); 
// 如 果 没 有 查找 到 ， et 节点 中 没有 此 路 径 下 对 应 的 信息 
if (nextInode == null) 
// 和 六 件 系统 的 
INodeDir<T> newDir = curInode.addDir (iPath, aUgi); 
newDir.InodeDirFs = getTargetFileSystem (newDir); 
// 并 以 此 作为 下 个 节点 ， 即 为 查找 到 的 目标 节点 


nextInode = newDir; 











} 
// 如 果 此 节点 已 经 是 INodeLink 信 息 ， 则 抛 异常 
if (nextInode instanceof INodeLink) { 
throw new FileAlreadyExistsException("Path " + nextInode.fullPath + 
本 人 exists as link"); 
} else 
// 名 来 还 是 INode 目 录 ， 则 将 子 目录 作为 当前 目录 ， 往 下 寻找 
assert (nextInode instanceof INodeDir); 
curInode = (INodeDir<T>) nextInode; 
} 
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找到 最 近 一 层 的 目录 树 后 ， 在 此 加 入 新 URI 的 Link 关 联 信 息 
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// 到 化 基本 投 到 了 最 底 度 的 站 对 ， 然后 在 此 目录 下 添加 INodeLink 链 接 
final INodeLink<T> newLink; 
final String fullPath = curInode.fullPath + (curInode == root ? ™™ : "/") 
+ iPath; 
// 将 目录 URI 链 接 等 信息 全 部 传 入 INodeLink 中 
if (isLinkMerge) { 
String[] targetsList = StringUtils.getStrings (target); 
URI[] targetsListURI = new URI[targetsList.length]; 
int k = 0; 
for (String itarget : targetsList) { 
targetsListURI [k++] = new URI (itarget); 
} 
newLink = new INodeLink<T> (fullPath, aUgi, 
getTargetFileSystem (targetsListURI), targetsListURI); 
} else { 
newLink = new INodeLink<T> (fullPath, aUgi, 
getTargetFileSystem (new URI (target)), new URI (target)); 


} 

// 将 构造 完毕 的 INodeLink 作 为 子 节点 加 入 到 当前 节点 中 
CurInode .addLink (iPath, newLink); 

// 同时 加 入 到 挂 载 节 点 列表 中 


mountPoints.add (new MountPoint<T> (src, newLink)); 
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可 以 看 到 ， 最 终 指向 的 文件 系统 和 具体 信息 都 在 INodeLink 中 。 所 有 的 挂 载 目录 点 的 位 置 都 以 字符 串 的 形式 被 树 形 地 拆 开 存 放 。 换 句 话 说， 在 ViewFilesystem 中 输入 一 个 ViewFilesystem 中 配置 的 查询 
路 径 ， 会 被 逐 层 解析 到 对 应 的 INodeDir。 图 3-2 为 INodeLink 存 储 结构 图 。 











INodeDir 


InodeDirFs(FileSystem) children(Map<String,INode<T>) 





ee INodeDir INodeLink 





isMergeLink targetDirLinkList(URI) targetFileSystem(FileSystem) 


图 3-2 INodeDir 存 储 结构 
解析 的 逻辑 与 此 完全 类 似 ， 也 是 通过 INodeDir 的 存储 关系 一 步 一 步 往 里 找 ， 这 里 就 不 展开 介绍 了 。 
3.ViewFileSystem 的 请 求 处 理 


现在 又 有 一 个 问题 出 现 了 ，ViewFileSystem 是 如 何 处 理 客户 端 发 来 的 各 种 文件 操作 请 求 的 呢 ?” 以 mkdir 为 例 : 





QOverride 
public boolean mkdirs (final Path dir, final FsPermission permission) 
throws IOException { 
// 通过 fsState 对 象 进行 解析 
InodeTree.ResolveResult<FileSystem> res = 
fsState.resolve (getUriPath (dir), false); 
// 获取 目标 真实 文件 系统 进行 对 应 的 请 求 处 理 
return res.targetFileSystem.mkdirs (res.remainingPath, permission); 
} 














这 里 的 fsState.resolve 就 会 到 之 前 提 到 的 挂 载 点 树 中 进行 逐 层 寻 找 。 找 到 对 应 的 文件 系统 后 ， 就 会 把 后 面 最 终 起 作用 的 路 径 作 为 参数 传 入 真实 的 文件 系统 中 。 














此 过 程 的 调用 流程 见 图 3-3。 









setAcl 





create 








MT NA 


fsState(InodeTree) 


resolve 





res.targetFileSystem.resolvePath 





3-3 ”ViewFs 的 路 径 解 析 











4.ViewFilesystem 的 路 径 包装 





ViewFilesystem 作 为 一 个 视图 文件 系统 ， 要 保持 在 逻辑 上 的 完全 一 致 ， 需 要 对 文件 返回 的 属性 信息 做 一 层 包装 和 适 配 。 











例如 ， 笔 者 事先 设 定 了 挂 载 信 息 : 





/project/viewFsTImp -> hdfs://nnl/projects/Tmp 





前 者 是 笔者 设 定 的 ViewFileSystem 路 径 ， 后 者 是 真实 文件 系统 存放 路 径 。 在 真实 文件 系统 中 假设 存在 3 个 子 文件 : 





/projects/Tmp/chilgd1l 
/projects/Tmp/chilgd2 
/projects/Tmp/chilg3 





在 ViewFileSystem 的 情况 下 ,我们 用 hadoop fs-ls/project/viewFsTmp 的 命令 去 看 ， 出 现 的 信息 应 该 是 这 样 的 : 





/projects/viewFsTmp/child1 
/projects/viewFsTmp/child2 
/projects/viewFsTmp/child3 





因为 挂 载 点 信息 文件 路 径 已 经 被 变更 了 ， 一 切 都 得 按照 ViewFileSystem 中 所 配置 的 路 径 来 ， 所 以 这 需要 我 们 对 真实 返回 的 FileStatus 文 件 信息 对 象 做 一 层 包 装 。 但 对 于 其 他 一 些 如 大 小 、 修 改 时 间 等 基 
本 属性 信息 ， 直 接 返 回 原来 的 信息 就 行 。 而 对 于 一 些 Path 的 返回 ， 就 要 做 一 层 修改 了 。 








于 是 就 衍生 出 了 ViewFsFileStatus 这 个 类 : 





class ViewFsFileStatus extends FileStatus { 

// 原 Filestatus 信 息 

final FileStatus myFs; 

// 修改 的 路 径 信息 

Path modifiedPath; 

ViewFsFileStatus (FileStatus fs, Path newPath) { 
myFs = fs; 
modifiedPath = newPath; 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 此 类 中 就 对 getPath 方 法 做 了 改动 : 





QOverride 
public Path getPath() { 
// 重 载 返 回路 径 的 方法 ， 返 回 的 是 修改 过 的 路 径 信息 


return modifiedPath; 























} 














对 于 其 他 基本 属性 方法 ， 直 接 调用 原来 的 方法 即 可 。 











http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 获取 副本 数量 信息 

QOverride 

public short getReplication () 
2 入 衣 奖 际 折 癌 的 间作 案 红 对 家 亲政 到 本 信息 ， 后 续 方 法 同 理 
return myFs.getReplication(); 

} 


QOverride 
public long getModificationTime () { 
return myFs.getModificationTime (); 


QOverride 
public long getAccessTime() { 
return myFs.getAccessTime (); 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








史 








这 就 实现 了 我 们 前 面 所 描述 的 例子 。 这 一 点 ， 大 家 可 以 可 以 在 自己 的 环境 中 进行 测试 。 图 3-4 是 ViewFsFilestatus 继 承 关 系 图 。 








extend 


FileStatus ViewFsFileStatus 





图 3-4 ViewFsFileStatus 的 继承 关系 


5.ViewFileSystem 性 能 优化 





这 里 的 ViewFileSystem 性 能 优化 点 主要 针对 执行 最 频繁 的 路 径 解 析 操 作 ， 这 里 其 实 可 以 有 比较 大 的 性 能 提升 。 在 前 文中 已 经 讲述 过 ， 目 前 ViewFileSystem 通 过 将 路 径 进 行 拆 分 ， 保 存 到 一 个 树 型 的 结构 
中 ， 解 析 时 同样 需要 拆 分 路 径 ， 进 行 逐 层 解 析 。 这 个 方法 本 身 没有 问题 ， 但 是 在 挂 载 表 数量 很 少 的 情况 下 ， 效 率 就 不 见得 很 高 了 。 而 且 频 繁 地 拆 分 、 合 并 字符 串 本 身 不 是 非常 高 效 的 操作 。 所 以 在 
ViewFilesystem 中 ， 声 明了 一 段 To-Do 的 声明 ， 就 是 将 来 可 以 做 的 改进 : “TO DO: 更 加 高 效 的 作法 不 是 分 解 整 个 path 路 径 而 是 做 简单 的 比较 。” 











也 就 是 说 ， 可 以 直接 保存 到 一 个 map 的 关系 结构 中 ， 然 后 直接 做 字符 串 的 简单 比较 ， 也 不 需要 保存 什么 复杂 的 父亲 -孩子 的 结构 。 当 然 这 是 对 挂 载 表 内 记录 比较 少 的 情况 。 而 且 我 们 选择 目录 映射 的 时 
候 ， 一 般 不 会 有 很 多 的 关系 ， 通 常 主要 映射 几 个 顶级 目录 就 可 以 了 ， 所 以 记录 数 也 不 会 很 多 。 当 然 如 果 将 来 改进 的 话 ， 那 么 添加 Link 和 解析 路 径 的 逻辑 都 要 变 。 

















3.1.3 ”ViewFileSystem 的 使 用 


最 后 简单 介绍 ViewFileSystem 的 配置 使 用 ， 主 要 分 为 两 个 步骤 。 
第 一 步 ， 创 建 Viewfs 名 称 。 


在 core-site.xml 中 配置 fs.defaultFS 属 性 ， 如 下 所 示 : 








<property> 
<name>fs.defaultFS</name> 
<value>viewfs://MultipleCluster</value> 
</property> 





第 二 步 ， 添 加 挂 载 关 系 : 





<property> 

<name>fs.viewfs.mounttable.MultipleCluster.1link./viewfstmp</name> 
<value>hgdfs://nnl/tmp</value> 

</property> 





这 里 的 nn1 就 是 真实 的 集群 路 径 。 注 意 这 里 的 fs.viewfs.mounttable.MultipleCluster.link 中 link 前 面 的 名 称 必须 与 之 前 Viewfs 中 定义 的 名 称 一 致 。 





经 过 这 2 个 步骤 ， 就 基本 完成 了 ViewFileSystem 的 配置 ， 其 实 非 常 简单 。 





























然后 用 fs-ls 的 命令 分 别 在 配置 前 和 配置 后 的 集群 中 运行 ， 你 会 发 现 它们 的 子 目录 文件 信息 完全 一 致 。 











配置 前 在 nn1 所 在 集群 内 的 执行 结果 : 





$ hadoop fs -1s /tmp 
Found 2 items 





-rw-r--r-- 2 data supergroup 193488274 2016-04-13 14:21 /tmp/share.tar.gz 
drwzxr-xr-x  - data supergroup 0 2016-03-15 15:39 /tmp/sparkjars 
配置 后 集群 中 的 执行 结果 





$ hadoop fs -ls /viewfstmp 
Found 2 items 


“EW a supergroup 193488274 2016-04-13 14:21 /viewfstmp/share.tar.gz 
Grwxr-xr-x  - data supergroup 0 2016-03-15 15:39 /viewfstmp/sparkjars 











倘若 你 在 配置 后 的 集群 中 还 是 用 hadoop fs-ls/tmp 去 查找 ， 它 会 报 找 不 到 文件 的 提示 。 











$ hadoop fs -1s /tmp 
1s:“/tmp': No such file or directory 








为 在 逻辑 上 ， 这 个 目录 已 经 被 挂 载 到 Viewfs 的 /viewfstmp 路 径 下 了 。 这 些 挂 载 信息 会 维护 在 客户 端的 内 存 中 ， 不 需要 重启 NameNode 和 DataNode。 








3.2 ”HDFS 的 Web 文 件 系 统 : WebHdfsFileSystem 
































在 HDFS 中 ， 如 果 用 户 想 要 对 HDFS 中 的 文件 或 目录 做 操作 ， 他 需要 了 解 NameNode 对 外 开发 的 方法 ， 然 后 调用 DFSClient 对 应 的 方法 。 对 于 一 个 天 天 使 用 HDFS 的 人 来 说 ， 这 非常 容易 。 但 是 对 于 之 前 
一 点 都 没有 接触 过 HDFS 的 人 来 说 ， 还 是 需要 一 定 的 学 习 成 本 的 。 对 于 这 种 情况 ，HDFS 内 部 提供 的 WebHdfsFileSystem 能 够 很 好 地 解决 这 个 问题 ， 而 且 它 能 够 帮助 用 户 很 容易 地 将 HDFS 中 的 文件 、 目 录 操 



















































































作 结 合 到 自己 的 系统 中 。WebHdfsFileSystem 让 HDFS 以 Web 的 形式 展现 给 用 户 ， 用 户 通过 调用 相应 的 REST API 即 可 完成 文件 、 目 录 的 操作 。 本 节 主 要 的 目标 是 让 大 家 了 解 以 及 使 用 
WebHdfsFileSystem， 具 体 的 内 容 包 括 HDFS Web 文 件 系统 REST API 的 设计 、 流 程 调用 以 及 使 用 方法 等 。 本 节 部 分 内 容 来 自 于 Hadoop 社 区 官方 文档 。 






























































3.2.1 WebHdfsFilesystem 的 REST API 操 作 


WebHdfsFilesystem 是 HDFS 以 Web 的 形式 呈现 出 的 一 种 文件 系统 。 既 然 是 Web 形 式 ， 所 以 它 有 很 关键 的 一 个 特性 : 通过 Web REST API 的 形式 对 文件 系统 进行 操作 。 也 就 是 说 ， 
求 url 的 形式 ， 对 HDFS 做 操作 ， 并 且 不 用 写 任何 客户 端 程序 。 


在 WebHdfsFileSystem 的 REST API 操 作 中 ， 所 有 的 方法 被 分 为 以 下 4 类 : 
"GET 
“PUT 
"POST 


“ DELETE 























对 于 不 同 操作 性 质 的 方法 ， 需 要 用 相应 的 REST API 类 型 。 比 如 获取 状态 信息 之 类 的 方法 ， 就 用 GET 请 求 的 方式 。 在 WebHdfsFilesystem 中 ， 同 样 对 自身 的 操作 方法 进行 了 类 型 划分 。 下 







































































户 可 以 通过 http 请 

















体 的 划分 











间 











结果 : 
1) GE 方式 。 
获取 文件 目录 信息 相关 : 
”OPEN 
“GET_FILE_STATUS 
“IIST_STATUS 
“GET_CONTENT_SUMMARY 
“GET_FILE_CHECKSUM 
“GET_HOME_DIRECTORY 


` GET_BLOCK_LOCATIONS 





获取 属性 、ACL 访 问 相关 : 
“ GET_DELEGATION_TOKEN 
GET _ XATTRS 

* LIST XATTRS 
"GET_ACL, STATUS 
“CHECK_ACCESS 

2) PUT 方式 。 
文件 目录 设置 相关 : 
"CREATE 

* MKDIRS 

* CREATE_SYMLINK 

* RENAME 

* SET_REPLICATION 

* SET_OWNER 

* SET_PERMISSION 


* SET_TIMES 





ACL 访 问 属性 相关 : 
“RENEW_DELEGATION_TOKEN 
CANCEL_DELEGATION_TOKEN 
“MODIFY_ACL_ENTRIES 


REMOVE_ACL_ENTRIES 


“ REMOVE_DEFAULT_ACL 
: REMOVE_ACL 

:SET_ACL 

: SET_XATTR 
:REMOVE_XATTR 

快照 操作 相关 : 

“ CREATE_SNAPSHOT 

: RENAME_SNAPSHOT 

3) POST 方式 : 

“ APPEND: 文件 追加 操作 

: CONCAT: 文件 拼接 操作 
“TRUNCATE: 文件 截断 操作 
4) DELETE 方 式 : 

“DELETE: 文件 /目录 删除 操作 


* DELETE_SNAPSHOT: 快照 删除 操作 


3.2.2 ”WebHdfsFileSystem 的 流程 调用 












































在 这 里 我 们 以 一 个 简单 的 请 求 为 例 ， 来 模拟 WebHdfsFileSystem 的 整体 调用 过 程 。 比 如 下 面 的 rename 操 作 ， 调 用 命令 如 下 : 





Curl -i -X PUT "<HOST>:<PORT>/webhdfs/v1/<PATH>?op=RENAME &destination=<PATH>" 











这 里 利用 curl 命 令 来 发 送 请 求 。 

















首先 这 个 请 求 会 调用 到 HDFS 客 户 端的 WebHdfsFileSystem 类 中 的 对 应 方法 : 














public boolean rename (final Path src, final Path dst) throws IOException { 
statistics.incrementWriteOps (1) 7 
// 构造 rename 操 作 类 型 
final HttpOpParam.Op op = PutOpParam.Op.RENAME; 
// 调用 FsPathBooleanRunner 执 行 器 进行 请 求 的 进一步 处 理 
return new FsPathBooleanRunner (op, src, 
new DestinationParam (makeQualified (dst) .toUri () .getPath () ) 
) .run(); 


} 




















FsPathBooleanRunner 具 体 如 何 执行 ， 后 面 会 具体 介绍 ， 这 里 先 跳 过 。 然 后 FsPathBoolean-Runner 的 run 方 法 将 会 调用 HDFS 服 务 端 的 NamenodeWebHdfsMethods 类 ， 这 个 类 包含 了 对 应 请 求 类 型 
的 处 理 方法 。 











private Response put( 
final UserGroupInformation ugi, 
final DelegationParam delegation, 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
) throws IOException, URISyntaxException { 


final Configuration conf = (Configuration)context.getAttribute (JspHelper .CURRENT CONF); 
final NameNode namenode = (NameNode)context.getAttribute ("name.node"); 
final NamenodeProtocols np = getRPCServer (namenode); 


switch(op.getValue()) { 
Case CREATE: 
//http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
Case MKDIRS: 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
Case CREATESYMLINK: 加 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// RENAME 操 作对 应 的 处 理 
Case RENAME: 
final EnumSet<Options.Rename> s = renameOptions.getValue(); 
// 执行 对 应 的 重 命名 方法 
if (s.isEmpty()) { 
final boolean b np.rename (fullpath, destination.getValue()); 
final String js = JsonUtil.toJsonstring ("boolean", b); 
return Response.ok (js) .type (MediaType.APPLICATION JSON) .build(); 
} else { 
np.rename2 (fullpath, destination.getValue(), 
Ss.toArray (new Options.Rename[s.size()])); 
return Response.ok () .type (MediaType.APPLICATION OCTET STREAM) .build(); 


} 





于 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
































最 后 np.rename 会 触发 对 FSNamesystem 的 调用 ， 也 就 最 终 完 成 了 整个 过 程 的 调用 。 整 个 流程 调用 过 程 见 图 3-5。 
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图 3-5 ”WebHdfsFileSystem 执 行 过 程 


3.2.3 ”WebHdfsFileSystem 执 行 器 调用 
前 面 rename 命 令 的 调用 过 程 会 经 过 FsPathBooleanRunner 执 行 器 的 处 理 。FsPath-BooleanRunner 本 身 是 AbstractRunner 的 子 类 ， 而 AbstractRunner 在 其 内 部 会 做 许多 事情 ， 包 括 : 
1) 初始 化 http 请 求 连接 。 
2) 连接 Server 端 。 
3) 获取 执行 回复 内 容 。 


4) 执行 失败 重 试 操作 。 
从 这 里 可 以 看 出 ，AbstractRunner 为 客户 端 免 去 了 一 些 公共 的 实现 细节 。 下 面 进入 run 方 法 ， 查 看 其 内 部 是 如 何 执行 这 些 操作 的 。 





T run() throws IOException { 
// 获取 当前 执行 用 户 信息 
UserGroupInformation connectUgi = ugi.getRealUser () 7 
if (connectUgi == null) { 
connectUgi = ugi; 


. 
if (op.getRequireAuth()) { 
connectUgi .checkTGTAndReloginFromKeytab (); 











try { 
// 连接 的 过 程 需 要 运行 在 doAs 方 法 内 ， 以 此 确保 中 间 认 证 过 程 的 正确 执行 
return connectUgi.doAs( 
new PrivilegedExceptionAction<T>() { 
QOverride 
public T run() throws IOException { 
// 以 重 试 策略 的 方式 执行 


return runWithRetry(); 





]) 7 
} catch (InterruptedException e) { 


throw new IOException (e); 
} 
} 





runWithRetry 方 法 的 代码 如 下 : 





private T runWithRetry() throws IOException { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 重新 计数 从 0 开始 

for (int retry = 0; ; retry++) { 
checkRetry = !redirected; 
final URL url = getUr1l (); 


try { 
// 根据 url 建 立 http 连 接 
final HttpURLConnection conn = connect (url); 
// 输出 流 在 关闭 的 时 候 需要 进行 验证 
if (!op.getDoOutpPut ()) { 
ValidqateResponse (op, conn, false); 


t 

// 获取 执行 回复 结果 

return getResponse (conn); 

catch (AccessControlException ace) { 

















http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





} catch (IOException ioe) 
// 发 生 异常 时 ， 判 断 是 否 需 要 重 试 
shouldRetry (ioe, retry); 
} 
} 








响应 回复 : 











当 连 接 出 现 失败 、NameNode 进 入 Standby 模 式 或 Server 端 执行 出 错 ， 都 会 导致 1/O 异 常 的 发 生 。 这 里 的 getResponse 是 抽象 方法 ， 它 会 根据 具体 子 类 需要 的 回复 格式 返回 相应 格式 的 内 容 。 在 一 般 的 








http 请 求 回复 中 ， 大 多 有 两 种 类 型 的 回复 方式 : 第 一 种 是 带 有 具体 信息 内 容 的 回复 ， 一 般 以 json 格 式 进行 返回 ; 第 二 种 ， 不 带 






































1) FsPathResponseRunner: 带 json 回 复 格 式 的 处 理 执行 器 。 这 类 执行 器 一 般 用 于 Get 类 型 的 操作 ， 比 如 getHdfsFileStatus 操 作 。 











2) FsPathRunner: 不 带 json 回 复 格 式 的 处 理 执行 器 ， 它 的 getResponse 返 回 内 容 为 空 ， 如 下 所 示 : 


体 信息 内 容 的 回复 。 在 WebHDFS 的 操作 响应 中 ， 总 共 分 出 了 以 下 4 种 类 型 的 





// 基于 路 径 实现 ， 并 且 无 json 回 复 的 处 理 类 
class FsPathRunner extends AbstractFsPathRunner<Void> { 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


QOverride 
Void getResponse (HttpURLConnection conn) throws IOException { 
return null; 
} 
} 





像 rename、setXAttr 这 样 的 操作 用 的 就 是 FsPathRunner 执 行 器 。 


3) FsPathConnectionRunner: 此 执行 器 的 回复 是 http 的 连接 对 象 。 





class FsPathConnectionRunner extends AbstractFsPathRunner<HttpURLConnection> { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


QOverride 
HttpURLConnection getResponse (final HttpURLConnection conn) 
throws IOException { 
return conn; 





单 的 操作 方式 会 导致 操作 的 误 用 和 恶意 使 
加 一 些 认 证 操作 来 规避 这 样 的 现象 。 在 WebHDFS 的 认证 方面 ， 社 区 已 经 有 了 一 定 的 进 | 








4) FsPathOutputStreamRunner: 用 以 处 理 创建 、 追 加 数据 流 。 








WebHdfsFilesystem 中 的 执行 器 结构 关系 见 图 3-6。 
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图 3-6 WebHdfsFileSystem 的 执行 器 继承 关系 














3.2.4 WebHDFS 的 OAuth2 认 证 




















AbstractFsPathRunner 


FsPathResponseRunner 





FsPathRunner 


WebHDFS REST API 的 出 现 ， 大 大 简化 了 用 户 使 用 HDFS 的 成 本 ， 用 户 只 需 通过 构造 简单 的 请 求 链接 就 可 以 达到 操作 HDFS 文 件 目录 的 效果 。 但 同时 另外 一 个 问题 也 随 之 而 来 ， 那 就 是 安全 问题 。 过 于 简 



































1.OAuth2 认 证 机 制 








OAuth2 是 OAuth 协 议 的 下 一 版 本 。 与 OAuth1.0 相 比 ，OAuth2 在 客户 端的 使 用 上 ， 更 加 简单 、 易 用 。 








OAuth2 认 证 将 会 涉及 以 下 3 个 角色 : 
“ 服务 端 : 用 户 使 用 服务 端 提供 的 各 个 资源 。 


“用户 : 服务 端 资源 的 真实 拥有 者 。 





用 。 用 户 只 需要 知道 目标 集群 NameNode 的 |p 和 目标 操作 文件 路 径 ， 就 可 以 对 其 进行 直接 操作 ， 这 至 少 听 上 去 还 是 比较 恐怖 的 。 因 此 我 们 需要 在 WebHDFS 内 部 增 
展 ，HDFS-8155 (Support OAuth2 in WebHDFS) 已 经 完成 了 在 WebHDFS 上 的 OAuth2 认 证 支持 。 





“ 客户 端 : 要 访问 服务 端 资源 的 第 三 方 应 用 。 





下 面 是 具体 的 认证 步骤 : 








1) 用 户 登录 客户 端 向 服务 端 请 求 一 个 








民 务 端 通过 客户 端 验证 后 ， 返 回 其 




















3) 客户 端 获取 临时 令 牌 后 ， 引 导 用 户 到 服务 端 提供 的 授权 页 面 。 





























4) 





户 输入 帐号 、 密 码 后 ， 表 明 用 户 授权 此 客户 端 访问 所 请 求 的 资源 。 








w 


授权 过 程 完 成 后 ， 客 户 端 根据 临时 令 牌 从 服务 端 获取 访问 令 牌 。 








6) 客户 端 获取 访问 令 牌 后 向 服务 端 访 问 受 保护 的 资源 。 











比较 常见 的 使 





QAuth2 认 证 的 一 个 场景 是 QQ 的 授权 认证 。 








2.WebHdfsFileSystem 的 OAuth2 认 证 调用 








WebHdfsFilesystem 的 OAuth2 认 证 调 上 








首先 是 在 initialize 方 法 中 进行 的 : 











public synchronized void initialize(URI uri, Configuration conf) 

throws IOException { 

super.initialize (uri, conf); 

setConf (conf); 

// 设置 用 户 相关 配置 参数 

UserParam. setUserPattern (conf .get ( 
HdfsClientConfigKeys.DFS WEBHDFS USER PATTERN KEY, 
HdfsClientConfigKeys .DFS ”WEBHDFS USER PATTERN | | _ DEFAULT) ); 

// 获取 是 否 启用 WebHdfs 的 OAuthe 认 证 ， 默 认 不 启用 

boolean isOAuth = conf.getBoolean( 
HdfsClientConfigKeys.DFS WEBHDFS OAUTH FNABLED KEY, 
HdfsClientConfigKeys.DFS WEBHDFS OAUTH ENABLED DEFAULT); 


if(isOAuth) { 
LOG.debug ("Enabling OAuth2 in WebHDFS"); 
// 如 果 启 用 了 OAuth2 的 认证 ， 贡 检 全 OACEE2 过 医生 造 器 
connectionFactory = URLConnectionFactory 
.newOAuth2URLConnectionFactory (conf); 


else { 

// 否则 构建 默认 连接 器 

LOG.debug ("Not enabling OAuth2 in WebHDFS"); 

connectionFactory = URLConnectionFactory 
.newDefaultURLConnectionFactory (conf); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach eb 


ook/uncompressed/16100/0EBPS/Text/... 





继续 进入 newOAuth2URLConnectionFactory 方 法 : 





public static URLConnectionFactory newORuth2URLConnectionFactory( 
Configuration conf) throws IOException { 
ConnectionConfigurator conn; 
try { 
ConnectionConfigurator sslConnConfigurator 
= newSslConnConfigurator (DEFAULT : SOCKET TIMEOUT, conf); 
// 构造 OAuth2 连 接 配置 器 
conn = new OAuth2ConnectionConfigurator (conf, sslConnConfigurator); 
} catch (Exception e) { 
throw new IOException("Unable to load OAuth2 connection factory.", e 
} 


return new URLConnectionFactory (Conn) 7 


); 





OAuth2ConnectionConfigurator 在 构造 函数 中 会 创建 accessTokenProvider 令 牌 提供 实例 对 象 。 





public OAuth2ConnectionConfigurator (Configuration conf, 


ConnectionConfigurator sslConfigurator) { 


this.sslConfigurator = sslConfigurator; 


notNull (conf, ACCESS TOKEN PROVIDER KEY); 


Class accessTokenProviderClass = 
ConfCredentialBasedAccessTokenProvider.class, 
AccessTokenProvider.class); 

// 在 连接 配置 器 中 ， 构 建 了 AccessTokenProvider 访 问 令 牌 提供 实例 

accessTokenProvider = (AccessTokenProvider) ReflectionUtils 
.newInstance (accessTokenProviderClass, conf); 

accessTokenProvider.setConf (conf); 


conf.getClass (ACCESS_ TOKEN PROVIDER KEY, 





之 后 OAuth2ConnectionConfigurator 连 接 器 会 在 配置 连接 的 时 候 使 用 OAuth2 的 令 牌 。 





public HttpURLConnection configure (HttPURLConnection conn) 
throws IOException { 
if(sslConfigurator != null) { 
sslConfigurator.configure (conn); 


上 

// 在 每 次 构建 连接 时 ， 会 从 AccessTokenProvider 中 获取 访问 令 牌 
String accessToken = accessTokenProvider.getAccessToken (); 
// 加 入 头 信息 中 


conn.setRequestProperty ("AUTHORIZATION", HEADER + accessToken) 


return conn; 























AccessTokenProvider 在 WebHDFS 中 有 不 同 的 实现 类 ， 具 体 实现 类 读者 可 以 自行 























3.2.5 ”WebHDFS 的 使 用 








WebHDFS 的 使 











可 以 通过 curl 命 令 来 操作 ， 比 如 下 面 的 rename 命 令 : 





查阅 org.apache.hadoop.hdfs.web.oauth2 包 下 以 AccessTokenProvider 名 称 结 





尾 的 相关 类 。 





Curl -i -X PUT "<HOST>:<PORT>/webhdfs/v1/<PRTH>?op=RENAME&destination=<PATH>" 














-X 后 面 代表 的 是 请 求 类 型 。 如 果 我 们 在 请 求 中 没有 额外 设置 








户 ， 


回 














可 能 会 报 出 权限 拒绝 的 错误 : 


{"RemoteException":{"exception":"AccessControlException", "javaClassName":"org.apache.hadoop.security.AccessControlException", "message":"Permission denied: user=dr.who, access=W 

















可 以 通过 添加 user.data=<USER> 的 方式 来 表明 当前 操作 的 用 户 。 





Curl -i -X PUT "<HOST>:<PORT>/webhdfs/v1/<PRTH>?user.name=<USER>op=RENAME&destination=<PRATH>" 





如 果 执 行 成 功 ， 客 户 端 将 会 得 到 成 功 的 回复 信息 : 


HTTP/1.1 200 OK 
Content-Type: application/json 
Transfer-Encoding: chunked 


{"boolean": true} 








更 多 有 关 WebHDFS 使 用 的 例子 可 以 阅读 Hadoop 官 网 的 例子 。 














3.3 ”HDFS 数 据 加 密 空间 : Encryption zone 




















在 之 前 第 2.5 节 中 我 们 介绍 了 HDFS 内 部 的 两 套 认证 体系 ， 在 一 定 程度 上 能 起 到 数据 保护 的 作用 。 在 本 节 中 ， 我 们 将 要 介绍 另外 一 套 机 制 : 数据 加 密 空间 (Encryption zone) 。Encryption zone 与 之 前 
的 BlockToken 验 证 相 比 ， 它 更 加 注重 于 空间 的 特点 ， 因 为 它 只 会 对 指定 路 径 空间 下 的 数据 文件 ， 做 加 、 解 密 操作 。 本 节 将 主要 介绍 Encryption zone 的 实现 原理 以 及 它 的 配置 使 用 两 方面 内 容 。 





















































3.3.1 _ Encryption zone 原理 介绍 





HDFS Encryption zone 加 密 空 间 是 一 种 端 到 端的 加 密 模 式 。 其 中 的 加 、 解 密 过 程 对 于 客户 端 来 说 是 完全 透明 的 。 数 据 在 客户 端 读 操作 的 时 候 被 解密 ， 当 数据 被 客户 端 写 的 时 候 进行 加 密 ， 所 以 HDFS 本 
身 并 不 是 一 个 主要 的 参与 者 。 形 象 地 说 ， 在 HDFS 中 你 看 到 的 只 是 一 堆 加 密 的 数据 流 。 














了 解 HDFS 数 据 加 密 空间 的 原理 对 于 我 们 使 用 Encryption zone 有 很 大 帮助 。Encryption zone 是 HDFS 中 的 一 个 抽象 概念 ， 它 表示 在 此 空间 下 的 数据 在 写 的 时 候 会 被 透明 地 加 密 ， 同 时 在 读 的 时 候 ， 被 透 
明 地 解密， 这 是 它 的 核心 所 在 。 以 下 具体 到 细小 的 细节 : 

















1) 每 个 encryption zone 会 与 每 个 encryption zone key 相 关联 ， 而 这 个 key 会 在 创建 encryption zone 的 时 候 被 指定 。 
2) 每 个 encryption zone 中 的 文件 会 有 其 唯一 的 data encryption key (数据 加 密 key) ,简称 DEK。 


3) DEK 不 会 被 HDFS 直 接 处 理 ，HDFS 只 处 理 经 过 加 密 的 DEK， 叫 做 encrypted data encryption key, 缩写 就 是 EDEK。 











4) 客户 端 请 求 KMS 服 务 去 解密 EDEK， 然 后 利用 解密 后 得 到 的 DEK 去 读 、 写 数据 。 



































在 第 四 步 中 有 一 个 很 重要 的 过 程 : 在 客户 端 向 KMS 服 务 请 求 的 上 时候， 会 有 相关 权限 的 验证 ， 不 符合 要 求 的 客户 端 将 不 会 得 到 解密 后 的 DEK。 而 且 KMS 的 权限 验证 是 独立 于 HDFS 的 ， 是 自身 的 一 套 权限 
验证 体系 。 




















到 3-7 是 Encryption zone 的 原理 图 。 


























Key Provider 可 以 理解 为 一 个 key store 的 保存 库 ， 其 中 KM S 是 其 中 的 一 个 实现 。 


3.3.2 “Encryption zone 源码 实现 





本 小 节 我 们 将 从 源码 的 层面 对 上 述 原理 做 跟踪 分 析 ， 从 两 大 方向 进行 分 析 : 一 个 是 创建 文件 ， 并 且 写 文件 数据 ; 另 一 个 是 读 文件 数据 。 








Encryption zone 





Client Key Provider 


提供 EDEK 







提供 EDEK 


NameNode 


图 3-7 Encryption zone 原理 图 


1.Encryption zone 下 的 写 文件 





首先 客户 端 发 起 创建 文件 请 求 ， 到 了 NameNode 这 边 ， 会 调用 startFile 方 法 ， 用 于 生成 DEK 和 EDEK: 





private HdfsFileStatus startFileInt (final String src, 
PermissionStatus permissions, String holder, String clientMachine, 
EnumSet<CreateFlag> flag, boolean createParent, short replication, 
long blockSize, CryptoProtocolVersion[] supportedVersions, 
boolean logRetryCache) 
throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
FSDirWriteFileOp.EncryptionKeyInfo ezInfo = null; 
// 判断 key provider 是 否 为 空 
if (provider != null) { 
readLock (); 
try { 
checkOperation (OperationCategory .READ); 
// 不 为 空 ， 就 生成 EncryptionKey info 
ezInfo = FSDirWriteFileOp 
.getEncryptionKeyInfo (this, pc, src, supportedVersions); 
} finally { 
readUnlock (); 
} 


// 生成 EDEK 人 信息， 如 果 ezInfo 不 为 空 
if (ezInfo != null) { 
// 然后 根据 ezInfo 的 key 名 称 生成 EDEK 信 息 到 ezInfo 中 
ezInfo.edek = FSDirEncryptionZoneOp 
.generateEncryptedDataEncryptionKey (dir, ezInfo.ezKeyName); 
} 


EncryptionFaultInJjector.getInstance () .startFileAfterGenerateKey (); 
} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


try { 
// 继续 调用 startFile 方 法 
stat = FSDirWriteFileOp.startFile (this, pc, src, permissions, holder, 
clientMachine, flag, createParent, 
replication, blockSize, ezInfo, 
toRemoveBlocks, logRetryCache); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





startFile 方 法 如 下 : 





static HdfsFileStatus startFile( 
FSNamesystem fsn, FSPermissionChecker pc, String src, 
PermissionStatus permissions, String holder, String clientMachine, 
EnumSet<CreateFlag> flag, boolean createParent, 
Short replication, long blockSize, 
EncryptionKeyInfo ezInfo, INode.BlocksMapUpdateInfo toRemoveBlocks, 
boolean logRetryEntry) 
throws IOException { 


assert fsn.hasWriteLock () 7 
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CipherSuite suite = null; 
CryptoProtocolVersion version = null; 
KeyProviderCryptoExtension.EncryptedKeyVersion edek = null; 


// 取出 ezInfo 中 的 关键 信息 
if (ezInfo != null) { 
edek = ezInfo.edek; 
suite = ezInfo.suite; 
version = ezInfo.protocolVersion; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


FileEncryptionIinfo feInfo = null; 


final Ha zone = FSDirEncryptionZoneOp.getEZForPath (fsd, iip); 
if (zone != null) 
// 如 区 入 日前 是 不 B2 加 密 空间 下 ， 但 是 缺少 了 加 密 相关 参数 
if (suite == null || edek == null) { 
throw new RetryStartFileException(); 


} 

// 如 果 前 面条 件 都 满足 了 ， 则 进行 EDEK 的 匹配 

final String ezKeyName = zone.getKeyName(); 

if (!ezKeyName.equals (edek.getEncryptionKeyName())) { 
throw new RetryStartFileException(); 





} 
// 传 入 到 FileEncryptionInfo 中 ，feInfo 将 会 被 设置 到 INode 文 件 中 
feInfo = new FileEncryptionIinfo (suite, version, 
edek.getEncryptedKeyVersion() .getMaterial (), 
edek.getEncryptedKeyIv (), 
ezKeyName, edek.getEncryptionKeyVersionName () ) 7 
} 
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完成 这 些 操 作 之 后 ， 将 会 返回 一 个 HDFSFileStatus 对 象 ， 此 对 象 将 会 被 DFSO-utputstream 利 用 。 下 











回 











是 客户 端 解密 PEDK 并 加 密 数据 的 








public HdfsDataOutputStream createWrappedoutputStream (DFSOutputStream dfsos, 
FileSystem.Statistics statistics, long startPos) throws IOException { 
// 取出 文件 中 的 加 密 信息 
final re ho feInfo = dfsos.getFileEncryptionInfo(); 
if (feInfo != null) 
// 文件 是 被 加 密 的 ， 击 要 包装 数据 流 为 加 密 流 
getCryptoProtocolVersion (feInfo); 
final CryptoCodec codec = getCryptoCodec (conf, feInfo); 
// 解密 feInfo 中 的 EDEK 的 信息 ， 其 中 会 向 KerProvider 进 行 请 求 
KeyVersion Cecryptec decryptEncryptedDataEncryptionKey (feInfo); 
// 然后 将 解密 后 的 信息 作为 参数 ， 痪 造 出 加 宫 输 出 流 
final CryptooutputStream cryptoOut = 
new CryptoOutputStream(dfsos, codec, 
decrypted.getMaterial (), feInfo.getIV(), startPos); 
return new HdfsDataOutputStream(cryptoout, statistics, startPos); 
} else { 
// 没有 FileEncryptionInfo 信 息 代 表 无 须 进行 加 密 
return new HdfsDataOutputSstream(dfsos, statistics, startPos); 























继续 查看 decryptEncryptedDataEncryptionKey 方 法 ， 验 证 


中 是 否 有 向 KeyProvider 请 求 服务 的 操作 。 





private KeyVersion decryptEncryptedDataEncryptionKey (FileEncryptionIinfo 
feInfo) throws IOException { 
try (TraceScope ignored = tracer.newScope ("decryptEDEK")) { 

/ 获取 keyProvider 服 务实 例 

KeyProvider provider = getKeyProvider () 7 

if (provider == null) { 

throw new IOException ("No KeyProvider is configured, cannot access" + 

"an encrypted file"); 


} 
// 获取 加 密 的 key version 
EncryptedKeyVersion ekv = EncryptedKeyVersion.createForDecryption( 
feInfo.getKeyName (), feInfo.getEzKeyVersionName(), feInfo.getIV(), 
feInfo.getEncryptedDataEncryptionKey ()); 
try { 
Kevb od dolerite on cryptoProvider = KeyProviderCryptoExtension 
.CreateKeyProviderCryptoExtension (provider); 
// 进行 解密 操作 
return cryptoProvider.decryptEncryptedKey (ekv); 
} catch (GeneralSecurityException e) { 
throw new IOException (e); 





构造 完 加 密 输出 流 对 象 CryptoOutputstream 之 后 ， 在 随后 的 写 操作 中 ， 数 据 都 会 额外 经 过 一 步 加 密 算 ; 








去 的 操作 。 此 部 分 的 过 程 调 

















加 
[ 








DFSClient#createFile 


FSNamesystem#startFile FSDirWriteFileOp. startFile 


返回 hfsFileStatus 至 


一 DFSOutputStream 


KeyProvider not null EncryptionZone not null 


得 到 feInfo 
并 用 于 构建 


EncryptionKeyInfo FileEncryptionInfo 
CryptoOQutputStream 


create Wrapped 
OutputStream 





图 3-8 Encryption zone 下 的 写 文 件 过 程 


2.Encryption zone 下 的 读 文件 


读 文 件 部 分 的 操作 与 写 文件 非常 类 似 。 首 先 构造 出 目标 文件 的 HDFSFileStatus 对 象 ， 然 后 取出 其 中 的 FileEncryptionInfo。 在 此 过 程 中 FileEncryptionInfo 会 被 设置 到 Located-Blocks 中 。 





Private static HdfsLocatedFileStatus createLocatedFileStatus( 
FSDirectory fsd, byte[] path, INodeAttributes nodeAttrs, 
byte storagePolicy, int snapshot, 
boolean isRawPath, INodesInPath iip) throws IOException { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 然后 设置 到 LocatedBlocks 中 
loc = fsd.getBlockManager () .createLocatedBlocks ( 
fileNode.getBlocks (snapshot), fileSize, isUc, 0L, size, false, 
inSnapshot, feInfo, ecPolicy); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
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息 会 以 参数 的 形式 传 入 到 DFSInputStream， 并 在 方法 fetchLocatedBlocksAndGetLastBlockLength 中 被 设置 到 相应 变量 中 去 。 





private long fetchLocatedBlocksAndGetLastBlockLength (boolean refresh) 
throws IOException { 
LocatedBlocks newInfo = locatedBlocks; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 将 locatedBlocks 中 的 EncryptionInfo 信 息 设置 到 变量 中 
fileEncryptionInfo = locatedBlocks.getFileEncryptionInfo(); 


return lastBlockBeingWrittenLength; 





此 信息 同样 会 被 取出 用 到 加 密 输入 流 中 。 





public HdfsDataInputStream CreateWrappedInPutStream(DFSInputStream dfsis) 

throws IOException { 

// 获取 文件 加 密 信息 

final FileEncryptionInfo feInfo = dfsis.getFileEncryptionIinfo(); 

if (feInfo != null) { 
// 文件 是 被 加 密 的 ， 包 装 数据 流 为 加 密 数 据 流 
getCryptoProtocolVersion (feInfo); 
final CryptoCodec codec = getCryptoCodec (conf, feInfo); 
// 解密 DEDK 
final KeyVersion decrypted = decryptEncryptedDataEncryptionKey (feInfo); 
// 构造 加 密 输 入 流 
final CryptoInputStream cryptoIn = 

new CryptoInputSstream(dfsis, codec, decrypted.getMaterial (), 
feInfo.getIV()); 

return new HdfsDataInputStream(cryptoIn); 

} else { 
// 没有 FileEncryptionInfo 人 信息， 无须 进行 加 密 操 作 
return new HdfsDataInputStream(dfsis); 





与 之 前 的 过 程 非常 类 似 ， 在 加 密 输入 流 中 ， 对 读 取 的 数据 进行 解密 ， 使 得 用 户 能 看 到 正常 的 数据 。 图 3-9 为 此 过 程 图 。 

















FileEncryptioninfo DFSIputStream 


得 到 feInfo 
并 用 于 构建 


createFileStatus createWrappedlnputStream 


LocatedBlocks 
CryptoinputStream 


图 3-9 ”Encryption zone 下 的 读 文件 过 程 


3.Encryption zone 的 管理 


在 源码 分 析 的 最 后 部 分 ， 再 简单 聊 聊 Encryption zone 的 管理 ， 对 应 的 管理 类 叫做 EncryptionZoneManager。 但 是 有 一 点 需要 注意 ， 它 内 部 维护 的 对 象 不 是 EncryptionZone， 而 是 


EncryptionZonelnt。 





public class EncryptionZoneManager { 


public static Logger LOG = LoggerFactory.getLogger (EncryptionZoneManager 
.Class); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 用 TreeMap 保 存 的 Encryption zone 列 表 

Private final TreeMap<Long, EncryptionZoneInt> encryptionZones; 

private final FSDirectory dir; 

private final int maxListEncryptionZonesResponses; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 






































这 里 TreeMap 的 key 位 置 保存 的 是 Encryption zone 对 应 目录 的 INodeld。EncryptionZonelnt 与 EncryptionZone 有 什么 微妙 的 关系 呢 ? 在 具体 使 用 的 时 候 ，EncryptionZonelnt 会 被 用 来 构造 
EncryptionZone， 代 码 如 下 : 





EncryptionZone getEZINoderForPath (INodesInPath iip) { 
final EncryptionZoneInt ezi = getEncryptionZoneForPath (iip); 
if (ezi == null) { 
return null; 


else { 
// 此 处 利用 EncryptionzZoneInt 对 象 信息 构造 EncryptionZone 对 象 
return new EncryptionZone (ezi .getINodeId(), getFullPathName (ezi), 
ezi.getSuite(), ezi.getVersion(), ezi.getKeyName()); 





通过 判断 目标 路 径 是 否 存 在 于 Encryption zone 列表 中 ， 来 判断 此 文件 是 否 为 加 密 文件 ， 然 后 以 INodeld 作 为 key 从 map 中 取出 。 





Encryption zone 的 结构 管理 见 图 3-10。 
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图 3-10 ”Encryptionzone 管 理 类 结构 





3.3.3 Encryption zone 的 使 用 

















Encryption zone 功能 的 配置 使 用 只 需 完成 以 下 几 个 相关 的 配置 项 即 可 。 








第 一 步 : 完成 keyProveider 的 配置 。 将 已 存在 的 keyProvider 的 URL 地 址 配置 到 下 面 的 配置 项 中 : 





dfs.encryption.key.provider.uri 








第 二 步 : 加 密 算法 相关 的 配置 。 主 要 有 以 下 的 一 些 配置 项 : 





hadoop. security.crypto.codec.classes .EXAMPLECIPHERSUITE 
hadoop. security.crypto.codec.classes.aes.ctr.nopadding 
hadoop.security.crypto.cipher.suite 
hadoop.security.crypto.jce.provider 

hadoop. security.crypto.buffer.size 
































这 些 配 置 项 并 不 需要 强制 性 的 配置 ， 采 用 默认 值 也 是 可 以 的 。 





























第 三 步 : 配置 listZone 响 应 回复 的 个 数 。 此 配置 项 会 在 listZones 的 命令 中 起 到 作用 。 





dfs.namenode.1ist.encryption.zones.num.responses 





第 四 步 : 创建 Encryption zone 加 密 空间 。 这 里 的 加 密 空间 是 针对 目录 级 别 的 ， 同 时 还 需要 设置 一 个 key 名 称 ， 使 用 的 命令 如 下 : 





hdfs crypto -createZone -keyName <keyName> -path <path> 














这 里 的 path 必 须 是 已 经 建 好 的 目录 ， 此 命令 的 作用 相当 于 将 目标 目录 作为 一 个 加 密 空间 ， 在 此 目录 下 的 文件 在 读 写 的 过 程 中 被 加 、 解 密 。 

















以 上 操作 完成 之 后 ， 加 密 空间 就 基本 创建 好 了 ， 可 以 用 listZones 的 命令 查看 当前 已 创建 好 的 加 密 空间 : 











hdfs crypto -listZones 

















下 面 举 几 个 官方 的 使 用 例子 : 





# 以 普通 用 户 的 身份 创建 一 个 加 密 key 


hadoop key create myKey 


# 以 超级 用 户 的 身份 创建 一 个 空 目录 ， 并 使 之 成 为 加 密 空 间 
hadoop fs -mkdir /zone 
hdfs crypto -createZone -keyName myKey -path /zone 


# 修改 此 目录 权限 为 普通 用 户 权限 


hadoop fs -chown myuser:myuser /zone 


# 以 普通 用 户 的 身份 进行 put 上 传 文件 和 cat 查 看 文件 操作 
hadoop fs -put helloWorld /zone 
hadoop fs -cat /zone/helloWorld 





3.4 ”HDFS 纠 删 码 技术 


HDFS 纠 删 码 技术 指 的 是 纠 删 码 算法 在 HDFS 中 的 实现 ， 简 称 HDFS EC。 纠 删 码 技术 是 一 种 用 于 数据 恢复 的 技术 。 它 对 于 HDFS 带 来 的 最 大 改变 是 可 以 使 得 HDFS 不 再 依靠 多 副本 机 制 来 达到 容错 的 效 


果 。 多 副本 机 制 的 一 个 很 大 的 头 端 在 于 它 对 于 存储 空间 的 极 大 浪费 ，HDFS 纠 删 码 技术 的 引入 将 会 极 大 地 改善 这 个 | 
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有 Edit OComment 
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Type: 
Priority: 
Affects Version/s: 


Component/s: 


个 Major 
None 
None 
None 
3.0.0 
Reviewed 


Labels: 
Target Version/s: 
Hadoop Flags: 


在 本 节 中 ， 我 们 首先 介绍 纠 删 码 技术 本 身 的 概念 以 及 优 劣势 。 随 后 介绍 HDFS 的 纠 删 码 技术 ， 学 习 了 解 纠 删 码 技术 在 HDFs 中 的 实现 原理 。 本 节 内 容 部 分 引 


3.4.1 纠 删 码 概念 


纠 删 码 技术 是 一 种 数据 恢复 技术 ， 最 早 用 于 通信 行业 中 数据 传输 中 的 数据 恢复 ， 是 一 种 编码 容错 技术 。 它 通过 在 原始 数据 中 加 入 新 的 校 验 数据 ， 使 得 各 


Assign 


New Feature 


Hadoop HDFS / HDFS-7285 


Erasure Coding Support inside HDFS 


More ~ 


Fix Version/s: 














3-11 HDFS EC 相关 JIRA 











出 错 情况 下 ， 通 过 纠 删 码 技术 都 可 以 进行 恢复 。 下 面 结合 轿 





片 进行 简单 演示 ， 


首先 有 原始 数据 n 个 ， 加 入 m 个 校 验 数据 块 ， 如 图 


Status: 


Resolution: 

















问题 。HDFS 纠 删 码 功能 将 发 布 于 Hadoop 3.0 版 本 ， 如 图 3-11 所 示 。 





Reopen lssue 


Fixed 
3.0.0 

















自 Apache 社 区 JIRA 上 EC 的 设计 文档 。 














个 部 分 的 数据 产生 关联 性 。 在 一 定 范围 内 的 数据 
3-12 所 示 。 


-= Stripe 
P1 


原始 数据 块 n 


检 : 


图 3-12 ”EC 数据 块 图 


W. 今 数 | 据 块 1 











Parity 部 分 就 是 校 验 数据 块 ， 我 们 把 一 行 数据 块 组 称 为 条 带 (strip) ， 每 行 条 带 由 n 个 数据 块 和 m 个 校 验 块 组 成 。 原 始 数据 块 和 校 验 数据 块 都 可 以 通过 现 有 的 数据 块 进行 恢复 ， 规 则 如 下 : 

















“ 如 果 校 验 数据 块 发 生 错 误 ， 通 过 对 原始 数据 块 进行 编码 重新 生成 。 


“ 如果 原始 数据 块 发 生 错误 ， 通 过 校 验 数据 块 的 解码 可 以 重新 生成 。 














而 且 m 和 nm 的 值 并 不 是 固定 不 变 的 ， 可 以 进行 相应 调整 。 可 能 有 人 会 好 奇 ， 这 其 中 到 底 是 什么 原理 呢 》 其 实 道理 很 简单 ， 我 们 把 上 面 的 图 片 看 成 矩阵 ， 由 于 矩阵 的 运算 具有 可 逆 性 ， 所 以 就 能 使 数据 进行 
恢复 ， 图 3-13 是 一 个 标准 的 矩阵 相 乘 图 ， 大 家 可 以 将 二 者 进行 关联 。 
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图 3-13 ”矩阵 相 乘 图 


至 于 里 面 涉及 的 数学 推理 ， 大 家 可 以 自行 寻找 资料 进行 学 习 。 








3.4.2 ” 纠 删 码 技术 的 优 劣 势 








优势 : 纠 删 码 技术 作为 一 门 数据 恢复 技术 ， 有 它 自 身 的 优势 。 它 可 以 解决 目前 分 布 式 系统 、 云 计算 中 采用 多 副本 机 制 来 防止 数据 丢失 的 问题 。 副 本 机 制 确实 可 以 解决 数据 丢失 的 问题 ， 但 是 会 使 存储 空 
间 翻 倍 并 很 快 耗 光 ， 这 一 点 是 非常 致命 的 。 EC 技术 的 运用 就 可 以 用 来 解决 这 个 问题 。 






























































劣势 : EC 技术 的 优势 确实 明显 ， 但 是 它 的 使 用 也 是 需要 付出 一 定 代价 的 。 一 旦 数据 需要 恢复 ， 它 会 造成 两 大 资源 的 消耗 : 

















:网络 带宽 的 消耗 ， 因 为 数据 恢复 需要 去 读 其 他 的 数据 块 和 校 验 块 。 


“ 进行 编码 、 解 码 计算 时 需要 消耗 CPU 资源 。 

















概况 来 讲 一 句 话 ， 就 是 既 耗 网 络 又 耗 CPU， 看 来 代价 也 不 小 。 所 以 这 么 来 看 ， 将 此 技术 数 用 于 线 上 服务 可 能 会 让 人 觉得 不 够 稳定 ， 所 以 最 好 的 选择 是 用 于 冷 数据 的 存储 。 以 下 两 点 原因 可 以 支持 这 种 选 



































“ 冷 数 据 集群 往往 有 大 量 的 长 期 没有 被 访问 的 数据 ， 数 据 规模 确实 会 比较 大 ， 采 用 EC 技术 ， 可 以 大 大 减少 副本 数 。 
“ 冷 数 据 集群 基本 稳定 ， 耗 资源 量 少 ， 所 以 一 旦 进行 数据 恢复 ， 也 将 不 会 对 集群 造成 大 的 影响 。 


出 于 上 述 两 种 原因 ， 冷 数据 的 存储 无 疑 是 一 个 很 好 的 选择 。 





3.4.3 ”Hadoop 纠 删 码 概述 


纠 删 码 技术 在 Hadoop 中 有 两 大 优势 : 
“ 存储 空间 的 节省 。EC 技 术 的 单 副 本 可 以 为 集群 节省 多 副本 机 制造 成 的 额外 存储 空间 的 使 用 。 这 也 是 EC 技术 被 运用 到 HDFS 中 的 一 个 很 重要 的 原因 。 


: 带宽 流量 的 节省 。EC 的 使 用 ， 会 使 得 写 入 集群 的 数据 总 量 减少 ， 进 一 步 为 集群 节省 了 带宽 的 消耗 。 但 是 同样 在 上 文中 也 已 经 提 到 过 ， 当 在 做 数据 恢复 的 时 候 会 比较 耗费 带宽 ， 因 为 它 会 从 其 他 多 个 节 
点 中 读 取 数据 进行 恢复 。 








在 Hadoop EC 的 设计 文档 中 ， 提 出 了 以 下 几 点 实现 目标 : 














1) 存储 空间 的 节省 。 








2) 灵活 的 存储 策略 ， 用 户 同样 能 够 标记 文件 为 HOT 或 COLD 存 储 类 型 。 



































3) 快速 的 恢复 与 转换 ， 同 时 在 数据 恢复 的 时 候 ， 需 要 尽 可 能 减少 网 络 带 宽 的 使 用 。 








4) 10 带 宽 的 节省 。 





5) NameNode 低 负载 。EC 技 术 在 一 定 程度 上 会 增 大 NameNode 的 开销 。 





为 NameNode 需 要 额外 跟踪 校 检 块 的 信息 。 在 EC 的 实现 过 程 中 ， 需 要 尽 可 能 降低 NameNode 的 负载 。 
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对 于 用 户 的 透明 性 、 兼 容 性 。EC 在 Hadoop 中 的 实现 细节 ， 需 要 保证 对 和 




















户 的 绝对 透明 。 而 且 上 














户 可 以 在 EC 策略 下 正常 使 用 其 他 功能 ， 例 如 HDFS 快 照 、HDFS 缓 存 、 加 密 空间 等 等 。 








这 里 还 有 一 点 需要 注意 ，EC 在 Hadoop 中 的 实现 会 直接 改变 原来 HDFS 默 认 的 























图 3-14 是 Hadoop EC 总 体 架构 





图 。 









BlockGroup 


ECSchema 











DataNode 






ECWorker 








仔细 观察 上 面 的 设计 图 ， 

















Hadoop EC 同样 采 


3.4.4 纠 删 码 技术 在 Hadoop 中 的 实现 








DataNode 
ECWorker 


ECWorker 





三 副本 策略 ， 而 副本 数 的 减少 会 对 MR 任务 的 数据 本 地 性 造成 一 定 影响 。 


NameNode 


ECManager 
BlockGroup 


ECSchema 





DataNode 


ECClient 


DataNode 





图 3-14 Hadoop EC 架构 设计 





图 








了 master/slave 的 主 从 结构 ， 在 NameNode、DataNode、Client 端 都 有 相应 的 服务 和 角色 。 





为 我 们 都 知道 ，Hadoop 作 为 一 个 成 熟 的 分 布 式 系统 ， 用 的 


是 三 副本 备份 的 策略 ， 所 以 这 项 技术 的 引入 对 于 Hadoop 本 身 来 说 ， 意 义 是 非常 重大 的 。 考 虑 到 EC 技术 在 Hadoop 中 的 实现 细节 会 比较 复杂 ， 所 以 这 里 不 会 逐 行 代码 地 进行 分 析 ， 主 要 从 大 的 方向 上 理 一 理 


它 的 实现 思路 。 
1.EC 概 念 在 Hadoop 中 的 演变 


EC 概念 指 的 是 数据 块 (data block) 、 校 验 块 (parity block) 、 条 带 (strip 
些 概念 的 定义 如 下 : 


“ 数据 块 、 校 验 块 在 HDFS 中 的 体现 就 是 普通 的 数据 块 。 


“ 条 带 的 概念 需要 将 每 个 块 进 行 分 裂 ， 每 个 块 由 若干 个 相同 大 小 的 单元 〈cell) 





3-15 为 HDFS 中 条 带 的 组 成 。 


| <- Striped Block Group -> | 
bik_0 blk_1 blk_2 


fbb 


Icell 2 


Icell 8| 


e) 等 这 些 概念 。 那 么 这 些 概念 在 HDFS 中 是 如 何 进行 转化 的 呢 ? 因 





为 要 想 实现 EC 技术 ， 至 少 在 概念 上 相同 的 。HDFS 对 这 


组 成 ， 每 个 条 带 由 一 行 单元 构成 ， 相 当 于 从 所 有 的 数据 块 和 校 验 块 抽取 出 了 一 行 。 


(*) blk_3 <— A striped block group 


Stripe 


+ 





Icell 6 


”Pe 


[Icell10 





+ 


Icell_7| 
—————+ 


|cell11 | 


图 3-15 Hadoop EC 的 stripe block group 














上 面 的 横竖 结构 可 以 看 出 很 像 之 前 提 到 的 和 矩阵。 为 什么 要 有 条 带 的 概念 是 因为 矩阵 运算 会 读 到 每 行 的 数据 。 接 下 来 我 们 放大 上 面 这 个 图 ， 见 图 3-16。 








在 这 里 还 需要 定义 一 些 逻 辑 上 的 概念 ， 主 要 为 下 面 2 个 逻辑 概念 : 











“ Block Group 的 组 概念 ， 图 中 第 一 个 矩阵 中 的 部 分 ， 训 辑 上 代表 一 个 HDFS 文 件 。 








:cell 概念 ， 就 是 从 逻辑 上 将 每 个 块 进行 单元 大 小 的 拆 分 ， 因 为 不 同 块 大 小 不 同 ， 所 以 不 同 块 的 单元 数量 可 能 也 会 不 同 。 


图 3-16 中 的 blk_0、blk_1、blk_2 才 是 最 终 存储 数据 的 块 ， 也 就 是 我 们 平常 说 的 HDFS 中 的 块 。 








range-reLated calculations are inclusive (the end 0 
range should be 1 byte lower t 


<— BLOCK Group: logical Unzit composing 
striped HDFS files., 
nterna ocks: each internal bloc 
represents a physically stored local 
block file 


{@link StripingCell} represents the 
logical order that a Block Group should 
be accessed: cell 8, cell 1, ... 


lIcell_6| |cell 7| lcell_8]|l 
+ + 十 十 十 十 
Icell_9| 





<-- A cell contains cellSize bytes of data 




















图 3-16 ”Hadoop EC 的 BlockGroup 详 细 结 构 











条 带 的 大 小 在 HDFS 中 的 计算 逻辑 如 下 : 





final int stripeSize = cellSize * numDataBlocks; 





stripeSize 就 是 一 行 的 大 小 。 获 取 块 长 度 的 实现 逻辑 如 下 : 





// 计算 每 个 条 带 的 大 小 (这 里 只 计算 数据 块 ) 
final int stripeSize = ce e * numDataBlocks; 
// 天 末 答 不 文生 站 靖 生 可 叶 宗 总 关 祭 ， 则 表明 下 面 的 所 属 块 都 是 一 样 的 大 小 
final int lastStripeDataLen = (int) (dataSize % stripeSize); 
if (lastStripeDataLen == 0) { 

return dataSsize / numDataBlocks; 


// 否则 根据 每 个 块 在 blockgroup 中 的 位 置 ， 判 断 是 否 还 要 另外 加 上 最 后 一 个 单元 的 大 小 
final int numStripes = (int) ((dataSize - 1) / stripeSize + 1); 
return (numStripes - 1L)*cellSize 

+ lastCellSize (lastStripeDataLen, cellSize, numDataBlocks, i); 





如 果 恰 好 最 后 一 行 条 带 长 度 为 0， 则 说 明 每 个 块 长 度 相 等 ， 直 接 返 回 即 可 ， 否 则 还 要 另外 加 上 lastCellSize 的 大 小 。 








2.HDFS 纠 删 码 的 实现 





了 解 完 概念 ， 下 面 开始 学 习 EC 在 HDFS 中 的 实现 。 本 节 主 要 讲述 EC 的 数据 恢复 过 程 ， 实 现代 码 主 要 在 ErasureCodingWorker 的 ReconstructAndTransferBlock 类 中 。 从 此 类 的 注释 中 可 以 获知 ， 此 过 程 
要 分 为 3 大 步 又: 





步骤 1: 根据 EC 数据 恢复 的 要 求 ， 至 少 保证 向 最 少 要 求 数量 的 源 端 节点 读 取 数 据 。 


步骤 2: 为 目标 节点 解码 数据 。 


现在 我 们 一 步 一 步 来 看 。 


根据 官方 注释 中 对 第 一 步骤 的 描述 ， 在 步骤 1 中 ， 至 少 向 最 少 要 求 数量 的 源 端 节点 读 取 绥 冲 数据 。 如 果 部 分 源 节 点 处 于 损坏 状态 或 是 数据 落后 的 状态 ， 将 会 选择 下 一 个 源 节点 。 最 好 的 源 节 点 会 被 记 住 并 


用 在 下 一 轮 的 数据 恢复 过 程 中 ， 当 然 也 可 能 在 每 一 轮 中 被 更 新 。 


概况 地 说 ， 就 是 它 首先 会 从 源 节 点 中 选 出 符合 度 最 高 的 n 个 节点 ， 如 果 节 点 中 有 坏 的 或 是 慢 节 点 ， 则 会 重新 进行 选择 ， 代 码 如 下 : 











py 区 时 全 读 取 最 少 要 求 数量 的 源 节 点 -| 全 人 的 大 全 
里 返回 的 success 列 表 就 是 要 真正 去 读 取 数据 的 节 
0 es i = new HashMap<>(); 
try { 
success = readMinimumStripedData4Reconstruction (success, 
ep corruptionMap); 
} finally 
wx 2 坏 块 到 NaneNoae 
reportCorruptedBlocks (corruptionMap); 
} 

















然后 会 对 每 个 源 节点 新 建 相应 的 StriperReader 对 象 以 进行 远程 读 取 ， 远 程 读 会 用 到 StriperReader 的 BlockReader 对 象 和 buffer 缓 冲 。 





private StripedReader aqddStripedReader (int i, long offsetInBlock) { 
final ExtendedBlock block = getBlock (blockGroup, liveIndices[i]); 
// 创建 StripedReader 对 象 ， 用 来 读 取 远程 数据 
StripedReader reader = new StripedReader (liveIndices[i], block, sources[i]); 
stripedReaders .add (reader); 


BlockReader blockReader = newBlockReader (block, offsetInBlock, sources[i]); 
if (blockReader != null) { 

initChecksumAndBufferSizeIfNeeded (blockReader); 

// StripedReader 实 质 读 取 数 据 的 对 象 是 BlockReader 

reader .blockReader = blockReagder; 


reader .buffer = allocateBuffer (bufferSize) 
return reader; 





StripedReader 结 构 如 图 3-17 所 示 。 





| <— Striped Block Group -> | 
blk 6 blk 1 blk 2(*) 人 <— A striped block 9roup 


| ceLLI6| 


|ceLLII| 


十 十 


We use followin 
We reconstruct <co ufferSize</code> data until finish, the 
<code>bufferSize</code> is configurable and may be less or larger than 
cell size: StripedReader.RemoteBlockReader 
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3-17 StripedReader 的 RemoteBlockReader 





步骤 1 的 总 过 程 见 图 3-18。 





readDataFromSourceNodes 
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3-18 ”ErasureCodingWorker 的 步骤 1 过 程 














在 步骤 2 中 ， 如 果 读 取 的 源 端 块 都 是 数据 块 类 型 的 ， 我 们 需要 调用 编码 操作 。 如 果 在 源 端 块 中 存在 一 个 校 验 块 ， 则 需要 调用 解码 操作 。 注 意 在 此 过 程 中 ， 只 会 读 取 数 据 一 次 ， 即 能 恢复 所 有 条 带 块 的 数 


























步骤 2 主要 点 在 于 编 解 码 数据 的 过 程 。 步 又 1 已 经 把 数据 读 到 缓冲 区 了 ， 步 又 2 就 是 计算 的 过 程 了 。 这 里 提 到 了 很 关键 的 一 点 : 如 果 读 取 的 源 端 块 都 是 数据 块 类 型 的 ， 需 要 调用 编码 操作 。 








编 解 码 操作 取决 于 恢复 的 对 象 ， 与 之 前 提 到 的 原则 是 一 致 的 。 相 关 代码 如 下 : 





// 步骤 2: 为 了 目标 块 ， 进 行 解码 恢复 操作 


reconstructTargets (success, targetsStatus, toReconstruct); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
int[] erasedIndices = getErasedIndices (targetsStatus); 
ByteBuffer[] outputs = new ByteBuffer[erasedIindices.length]; 
int m= 0; 
for (int i = 0; i < targetBuffers.length; i++) { 
if (targetsStatus[i]) { 
targetBuffers[i].limit (toReconstructLen); 
outputs [m++] = targetBuffers[i]; 


decoder .qdqecode (inputs, erasedIndices, outputs); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








这 里 使 用 的 是 解码 的 操作 ， 说 明 恢 复 的 块 是 数据 块 。 

















步骤 3 就 很 简单 了 ， 主 要 是 传输 数据 的 操作 。 将 缓冲 中 的 缓冲 数据 写 入 到 目标 节点 即 可 。 下 面 是 此 过 程 的 详细 说 明 : 在 步骤 3 中 ， 直 接 发 送 恢 复 好 的 数据 到 目标 节点 。 这 与 连续 分 配 式 的 块 副 本 相似 , 我 
们 不 需要 检查 每 个 数据 包 的 回复 。 由 于 做 数据 恢复 的 DataNode 是 源 节点 中 的 其 中 一 个 节点 ， 所 以 这 些 恢复 好 后 的 数据 是 以 远程 的 方式 发 送 到 目标 节点 。 





























写 的 方式 很 简单 ， 直 接 远程 写 即 可 ， 因 为 此 类 写 操作 只 涉及 一 个 节点 ， 无 需 构建 后 续 Pipeline 的 动作 。 











// 步骤 3: 传输 数据 到 目标 节点 

if (transferData2Targets (targetsStatus) == 0) { 
String error = "Transfer failed for all targets."7 
throw new IOException (error); 


bE: 











网 














以 上 就 是 Hadoop 3.0 中 EC 数据 恢复 技术 的 恢复 过 程 。 图 3-19 为 完整 流程 图 。 








步骤 1 步骤 2 步 又 3 


SC transferData2Targets 


toadDataEromSoursoNodes (decode to reconstruct targets) 











3-19 ”Hadoop EC 数据 恢复 步骤 








3. 改 进 优化 点 
在 官方 注释 中 提 到 了 2 个 优化 点 ， 在 后 续 应 该 会 被 完善 。 
“ 目前 的 数据 没有 采用 本 地 读 的 方式 ， 一 律 用 远程 方式 进行 数据 读 取 。 


“ 目标 数据 的 恢复 传输 并 不 返回 数据 包 的 确认 码 ， 不 像 Pipeline 那 样 有 很 健全 的 一 套 体 系 。 

















HDFS EC 将 会 在 Hadoop 3.0 版 本 中 发 布 ， 目 前 社区 已 经 发 布 了 3.0 alpha 版 本 ， 大 家 可 以 提前 试用 此 功能 。 





3.5 ”HDFS 对 象 存 储 : Ozone 


对 象 存储 是 目前 比较 主流 的 服务 存储 形式 ， 举 两 个 比较 典型 的 例子 : 亚马逊 的 S3 存 储 和 阿里 云 的 OSS 存 储 。 对 象 存储 指 的 是 目标 数据 从 对 象 中 进行 读 写 ， 然 后 通过 键 值 获取 对 应 的 对 象 。 整 个 存储 的 形 
式 为 key-object 的 存储 方式 ， 这 样 的 好 处 在 于 方便 用 户 的 使 用 ， 不 需要 走 复杂 的 操作 流程 。 本 节 所 要 讲述 的 则 是 HDFS 中 的 对 象 存储 ， 在 HDFS 中 我 们 也 可 以 做 到 基于 对 象 的 存储 。 目 前 此 功能 正在 开发 中 ， 
名 叫 Ozone， 相 关 社 区 JIRA: HDFS-7240 (Object store in HDFS) 。 在 本 节 中 ， 我 们 偏向 于 介绍 HDFS Ozone 的 理论 设计 ， 因 为 它 在 很 多 层面 与 现 有 HDFS 的 存储 方式 存在 着 比较 大 的 差异 。 在 理论 设计 
方面 ， 我 们 将 主要 讲述 它 的 实现 要 求 、 高 层 设计 以 及 部 分 细节 的 设计 。 在 本 节 未 尾 ， 还 会 给 出 一 个 实际 使 用 的 例子 。 本 节 部 分 内 容 引用 自 社区 儿 RA 上 Ozone 的 设计 文档 ， 链 接 如 下 : 

















































































































https://issues.apache.org/jira/secure/attachment/12724042/Ozone-architecture-v1.pdf。 


3.5.1 Ozone 介绍 





不 管 在 亚马逊 的 S3 服 务 还 是 阿里 云 的 OSS 服 务 ， 它 们 提供 的 服务 都 是 基于 key-object 键 值 对 的 服务 形式 。 而 且 它们 很 多 的 概念 都 比较 类 似 ， 比 如 bucket、object 的 定义 。object 是 最 小 粒度 级 别 的 单 
位 ， 代 表 的 是 最 终 存 储 数据 的 那个 对 象 。 而 bucket 则 是 其 上 一 级 的 组 织 对 象 。 一 个 bucket 下 可 以 有 一 个 或 多 个 object。 但 是 在 bucket 上 一 级 的 结构 ， 就 不 一 定 都 相同 了 ， 比 如 说 你 可 以 设计 成 每 个 用 户 只 
能 拥有 其 唯一 对 应 的 bucket， 又 或 者 声明 一 个 对 象 来 管理 这 些 bucket。 而 在 Ozone 的 设计 中 采用 了 后 者 的 做 法 。 在 Ozone 中 ，bucket 存 在 于 StorageVolume 中 ， 并 且 在 StorageVolume 中 拥有 了 唯一 的 名 
称 。StorageVolume 会 对 其 所 包含 的 bucket 对 象 进行 数量 上 的 配额 限制 。 借 此 管理 员 可 以 分 配 许多 有 配额 限制 的 StorageVolume 给 不 同 的 用 户 。 所 以 在 Qzone 中 ， 每 个 用 户 直 接 对 应 的 是 StorageVolume 


而 不 是 一 堆 的 bucket 列 表 。 其 中 bucket 等 概念 的 命名 规则 如 下 : 

































































一 个 bucket 被 两 部 分 名 字 组 合 所 唯一 标识 : storageVolumeName/bucketName。 一 个 object 的 名 称 则 被 storageVolumeName/bucketName/objectKey 三 部 分 所 标识 。 








Ozone 的 数据 组 织 结构 如 图 3-20 所 示 。 











aa 
Data Data 
K1,01 K1,01 
K2,02 K2,02 


图 3-20 Ozone 的 数据 组 织 结构 
在 HDFS Ozone 的 设计 中 ， 需 要 满足 以 下 一 些 基本 要 求 点 : 
. 管理 员 创建 storageVolume。 
“ 创建 /删除 bucket。 每 个 bucket 拥 有 一 个 独立 的 URL，bucket 不 能 被 重 命名 。 只 有 StorageVolume 的 所 属 者 或 所 属 组 才能 创建 /删除 volume 中 的 bucket。 
“ 在 一 个 StorageVolume 中 列 出 bucket 列 表 。 
“ 根据 给 定 的 key 在 bucket 中 创建 /删除 object 对 象 。 对 象 的 数据 或 值 可 以 流 式 地 传输 到 Ozone 服 务 中 。 当 对 象 被 写 满 的 时 候 将 只 会 允许 读 操 作 ， 同 时 不 保证 对 象 的 局 部 写 。 
“ 列举 出 bucket 的 内 容 。 


' 创建 /更 新 /删除 bucket 的 ACL 访 问 控制 列表 。 





我 们 可 以 看 到 ， 上 面 的 一 些 基本 要 求 在 实际 应 用 场景 中 还 是 很 常用 的 。 其 中 对 于 bucket、object 这 些 概念 具体 的 设计 要 求 ， 大 家 可 以 详细 阅读 前 文中 提 到 的 Ozone 的 设计 文档 链接 ， 在 此 不 再 详细 介 


绍 。 


3.5.2 ”Ozone 的 高 层级 设计 
1. 与 HDFS 共 享 DataNode 数 据 存储 


Ozone 的 出 现 使 得 HDFS 在 使 用 方式 上 将 会 与 原来 块 数据 读 写 的 方式 有 很 大 不 同 ， 所 以 在 这 里 我 们 将 会 以 一 个 独立 的 block pool 来 存储 Ozone 上 的 数据 。 也 就 是 说 DataNode 会 同时 为 HDFS 的 block 
pool 和 Ozone 的 block pool 存 储 数 据 。 同 样 的 ，Ozone 的 block pool 也 可 以 为 多 个 ， 分 别 代表 多 个 不 同 的 Ozone 的 命名 空间 。 关 系 结构 如 图 3-21 所 示 。 








Ozone Block Pool HDFS Block Pool 
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图 3-21 HDFS 和 Ozone 的 BlockPool 结 构 


2. 存 储 容器 (Storage Container) 


一 个 存储 容器 从 概念 上 来 说 ， 指 的 是 用 来 存储 Ozone 数 据 (其 实 也 是 bucket 中 的 数据 ) 和 Ozone 元 数据 的 一 个 存储 单元 。 存 储 容器 与 HDFS 的 块 一 样 ， 共 同 存储 于 DataNode 上 。 但 是 与 HDFS 不 同 的 一 
点 ，Ozone 没 有 一 个 类 似 于 NameNode 这 样 的 中 心 控制 节点 。 相 反 它 是 一 个 分 离 的 元 数据 的 存储 与 管理 器 ， 这 些 元 数据 分 布 式 地 存在 于 各 个 存储 容器 中 。 








一 个 bucket 可 以 拥有 百 万 数量 级 的 对 象 并 且 在 存储 的 大 小 级 别 上 可 以 达到 TB 级 别 ， 这 远 远 大 于 一 个 存储 容器 所 能 承受 的 (此 处 可 以 类 比 于 块 ) 。 因 此 一 个 bucket 会 被 分 为 很 多 分 区 (partion) ， 每 片 
分 区 会 存储 在 一 个 存储 容器 中 。 (一 个 存储 容器 可 以 包含 最 大 值 数量 的 分 区 ， 然 而 对 象 只 能 来 自 一 个 bucket) 在 目前 的 初始 设计 实现 中 ， 为 了 实现 的 简易 性 ， 一 个 object 对 象 完全 存在 于 单一 存储 容器 中 。 





3. 存 储 容器 标识 符 
每 个 存储 容器 会 被 独立 的 storage container 标 识 符 所 独立 标识 ， 它 是 一 个 逻辑 上 的 独立 标识 (类 似 于 HDFS 中 的 块 Id) 。 


对 象 的 key 会 映射 到 storage container 标 识 符 。 这 个 标识 符 会 传 入 Storage Container Manager (存储 容器 管理 器 ) 中 来 定位 包含 目标 对 象 容器 所 在 的 DataNode。 在 此 ，Storage Contain Manager 
可 以 完全 理解 为 BlockManager 的 角色 。 类 似 的 ，bucket 的 名 称 也 会 映射 到 storage container 标 识 符 ， 这 个 容器 保存 有 bucket 的 元 数据 。 在 后 面 的 小 节 中 ， 我 们 会 具体 提 到 这 个 映射 关系 是 如 何 实现 的 。 
在 存储 容器 相关 的 设计 实现 中 ， 要 满足 尽 可 能 复 用 已 有 代码 的 原则 。 


4.Storage Container Service 中 的 过 程 调 用 











图 3-22 展 示 了 Ozone 中 的 过 程 调用 ， 其 中 包含 了 Storage Container Service 服 务 和 Ozone Handler。 








5.DataNode 中 的 Ozone Handler 


Ozone Handler 是 Ozone 中 的 模块 组 件 ， 被 DataNode 所 持 有 并 对 外 提供 Ozone 服 务 。Handler 中 包含 了 一 个 HTTP 服 务 器 并 实现 了 Ozone REST API。Ozone Handler 与 Storage Container 
Manager 之 间 进 行 交互 来 查询 容器 的 位 置 ， 与 DataNode 中 的 存储 容器 交互 实现 不 同 的 操作 。 如 果 用 户 只 想 要 使 用 HDFS 的 文件 块 功能 而 不 需要 Ozone 功 能 这 个 功能 组 件 可 以 被 禁用 。 


6.Storage Container Manager 


Storage Container Manager 非 常 类 似 于 HDFS 中 BlockManager 的 角色 。Storage Container Manager 从 各 个 DataNode 中 收集 心跳 ， 处 理 存储 容器 的 报告 并 跟踪 每 个 存储 容器 的 位 置 。 它 在 内 部 维 
护 了 一 个 存储 容器 映射 图 ， 用 前 缀 匹配 的 方式 来 查询 存储 容器 。 图 3-23 为 storage Container Manager 与 DataNode 的 交互 图 。 
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图 3-22 ”Storage Container Service 过 程 调用 
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图 3-23 ”Storage Container Manager 与 DataNode 的 交互 








3.5.3 ”Ozone 的 实现 细节 


1. 映 射 object-key 到 存储 容器 

















下 面 再 来 看 看 其 中 的 一 些 细节 实现 。 其 中 大 家 比较 关心 的 一 点 在 于 key-object 到 存储 容器 的 映射 。 因 为 对 于 用 户 而 言 ， 他 所 面 对 的 就 是 一 个 key， 那 么 我 们 如 何 找到 它 对 应 存储 在 存储 容器 中 的 object 的 
数据 呢 ? 在 Ozone 中 ， 采 用 哈 希 分 区 的 方式 来 映射 key 到 它 所 存储 的 存储 容器 。 当 容器 逐渐 变 大 ， 我 们 会 对 此 进行 分 割 ， 并 用 扩展 哈 希 算法 重新 映射 key 到 对 应 的 容器 。 同 时 在 Storage Container 
Manager 中 更 新 此 映射 关系 。 





















































2. 存 储 容器 的 实现 

















在 前 文中 我 们 已 经 提 到 过 ， 存 储 容 器 完全 类 比 于 HDFS 中 的 块 ， 这 样 可 以 尽 可 能 地 复 用 HDFS 现 有 的 block pool 管 理 方面 的 功能 代码 。 因 此 我 们 会 将 存储 容器 作为 block 类 的 扩展 类 来 实现 。 一 个 HDFS 块 
由 一 个 标识 符 、 生 成 时 间 记 录 和 大 小 组 成 。 这 三 个 属性 同样 可 以 应 用 到 存储 容器 中 。 












































而 在 数据 的 一 致 性 上 ， 我 们 需要 为 存储 容器 实现 一 个 新 的 Pipeline 机 制 。 因 为 它 将 要 求 一 套 新 的 错误 恢复 机 制 。 





3.5.4 ”Ozone 的 使 用 














由 于 目前 HDFS Ozone 的 开发 工作 是 基于 分 支 HDFS-7240 的 ， 还 没 合 入 trunk， 所 以 我 们 获取 hadoop-trunk 的 代码 后 得 先 切 换 一 下 分 支 。 学 习 一 个 新 的 功能 特性 最 快 的 方法 是 从 看 懂 它 的 单元 测试 开 
始 ， 笔 者 挑选 了 下 面 一 个 典型 的 例子 ， 在 这 个 例子 中 ， 我 们 将 会 看 到 volume、bucket、object 的 数据 是 如 何 运用 的 。 























// 0zone 的 使 用 方法 测试 
@Test 
public void testPutAndGetMultiChunkKey() throws Exception { 
// 定义 一 个 待 添加 的 volume 的 名 称 
String volumeName = nextId("volume"); 
// 定义 一 个 待 添加 的 bucket 的 名 称 
String bucketName = nextId("bucket"); 
// 定义 一 个 待 创建 的 key 的 名 称 
String keyName = nextId("key 
// 定义 待 各 cy 册 认 家 的 笋 所 类 信 
int keyDataLen = 3 * CHUNK SIZE; 
// 创建 待 写 入 的 数据 
String keyData = buildKeyData (keyDataLen) ; 
// 在 0zone 中 创建 一 个 volume 
OzoneVolume volume = ozoneClient.createVolume (volumeName, "bilbo", "100TB"); 
assertNotNull (volume); 
// 获取 此 volume， 并 检验 此 volume 的 信息 是 否 为 我 们 所 期 望 的 
assertEquals (volumeName, volume.getVolumeName ()); 
assertEquals (ozoneClient .getUserAuth(), volume.getCreatedby ()); 
assertEquals ("bilbo", volume.getOwnerName()); 
assertNotNull (volume .getQuota ()); 
// 比较 Volume 的 限制 值 是 否 也 是 对 的 
assertEquals (OzoneQuota.parseQuota ("100TB") .sizeInBytes ()， 
Volume .getQuota () .sizeInBytes ()); 


// 在 此 volume 下 新 建 bucket 

OzoneBucket bucket = volume.createBucket (bucketName); 
// 检测 此 bucket 不 为 空 

assertNotNull (bucket) 

// 检测 此 bucket 是 我 们 所 期 望 创建 的 名 称 

assertEquals (bucketName，bucket.getBucketName () ) 


Af 人 
bucket .putKey (keyName, keyData) 

// 传 入 key， 审 行 受气 的 隆 取 ， 莉 断 数据 是 否 一 EE 
assertEquals (keyData, bucket .getKey (keyName)); 






































通过 上 面 的 例子 我 们 可 以 看 出 ，Ozone 使 用 的 方式 非常 简单 ， 根 本 无 须 写 任何 关于 DFSClient 端 读 写 文件 数据 的 代码 。 但 是 同样 需要 指出 的 是 ， 由 于 Ozone 的 使 用 方式 完全 独立 于 现 有 的 NameNode、 
DataNode 之 间 块 数据 管理 的 形式 ， 因 此 HDFS 目 前 主要 的 一 些 功能 特性 可 能 无 法 运用 在 Ozone 上 。Ozone 的 出 现 应 该 说 丰富 了 大 家 使 用 HDFS 的 方式 ， 至 少 如 果 我 们 想 做 对 象 存储 的 话 ， 就 不 用 单独 搞 另 外 
一 套 系统 来 实现 了 。 



























































3.6 小 结 





























本 章 主要 讲述 了 HDFS 内 部 一 些 用 户 熟 悉 度 较 低 的 功能 特性 。 在 这 些 特 性 中 ，ViewFs 和 WebHDFS 比 较 实 用 ， 大 家 只 需 理解 其 原理 并 懂得 如 何 使 用 即 可 。 而 本 章 的 难点 在 于 剩 下 的 三 节 : HDFS EC、 
Encryption zone 和 Ozone。 这 三 节 涉及 一 些 数学 的 算法 以 及 抽象 的 设计 思想 ， 对 于 这 三 节 的 学 习 ， 需 要 读者 反复 阅读 与 理解 。 

















二 部 分 “细节 实现 篇 
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本 章 主要 介绍 HDFS 存 储 数 据 的 最 小 单元 : 块 。 了 解 块 处 理 过 程 对 于 排除 问题 具有 十 分 重要 的 意义 。 本 章 分 为 三 个 方面 。 首 先 介绍 块 检查 命令 fsck， 此 节 将 会 告诉 我 们 块 丢失 了 。 其 次 介绍 HDFS 
中 多 余 块 的 删除 方法 。 最 后 介绍 块 的 上 报 处 理 过 程 ， 了 解 块 在 NameNode 中 的 周转 过 程 。 


























第 二 部 分 “细节 实现 篇 


第 4 章 ”HDFS 的 块 处 理 


























本 章 主要 介绍 HDFS 存 储 数据 的 最 小 单元 : 块 。 了 解 块 处 理 过 程 对 于 排除 问题 具有 十 分 重要 的 意义 。 本 章 分 为 三 个 方面 。 首 先 介绍 块 检查 命令 fsck， 此 节 将 会 告诉 我 们 块 丢失 了 怎么 查 。 其 次 介绍 HDFS 
中 多 余 块 的 删除 方法 。 最 后 介绍 块 的 上 报 处 理 过 程 ， 了 解 块 在 NameNode 中 的 周转 过 程 。 



































4.1 HDFS 块 检查 命令 fsck 














在 HDFS 中 ， 所 有 的 文件 都 是 以 块 的 形式 存在 的 。 集 群 在 运行 过 程 中 难免 会 发 生 块 损坏 的 情况 ， 这 个 时 候 就 可 以 使 用 HDFS 的 块 检查 命令 : fsck。 在 这 个 工具 命令 下 ， 不 仅仅 有 用 于 检测 坏 块 的 子 命令 ， 
还 有 相应 的 处 理 命令 ， 在 很 多 时 候 可 以 帮助 我 们 轻松 地 清理 集群 中 的 损坏 文件 。 本 节 将 要 介绍 fsck 命 令 的 使 用 场景 、fsck 命 令 各 个 参数 的 使 用 和 fsck 块 检查 命令 的 调用 过 程 。 























其 实 对 于 fsck 命 令 本身 ， 熟 悉 Linux 操 作 系统 的 人 ， 可 能 或 多 或 少 听 过 或 使 用 过 。fsck 命 令 的 全 称 是 file system check， 意 为 文件 系统 检测 命令 ， 此 命令 可 以 作为 一 种 修复 命令 。 本 节 不 会 介绍 操作 系统 
的 fsck 怎 么 用 ， 主 要 讲述 HDFS 下 fsck 的 使 用 ，bin/hdfs fsck 命 令 下 包含 有 很 多 可 选 参数 。 
































4.1.1 fsck 参数 使 用 














笔者 在 测试 集群 中 输入 hdfs fsck 命 令 后 ， 获 取 了 如 下 帮助 信息 ， 在 此 信息 中 展示 了 最 全 的 参数 使 用 说 明 : 























$ hdfs fsck 
Usage: hdfs fsck <path> [-list-corruptfileblocks | [-move | -delete | -openforwrite] [-files [-blocks [-locations | -racks]]]] 





“ <path> 目 标 扫描 的 路 径 名 称 

: -move 移 动 损 坏 的 文件 到 /lost+found 目 录 下 

“ -delete 删 除 损坏 的 文件 

-files 输出 被 检测 到 的 文件 

-openforwrite 输 出 正在 被 写 的 文件 

“ -includeSnapshots 如 果 检 测 的 路 径 下 包含 了 快照 目录 的 话 ， 输 出 快照 信息 
“ -list-corruptfileblocks 输 出 损坏 的 块 信息 

“ -blocks 输 出 块 的 报告 信息 

“ -locations 输 出 每 个 块 的 位 置信 息 

“ -Tacks 输 出 块 所 属 节点 的 机 架 信息 

-storagepolicies 输 出 块 上 设置 的 存储 策略 信息 

“ -blockId 输 出 指定 块 Id 对 应 的 块 信息 、 所 在 机 架 信 息 等 等 


简单 对 上 面 的 命令 进行 总 结 ， 首 先是 必 填 参数 和 命令 名 : 





bin/hdfs fsck <path> 





然后 是 以 下 可 选 参数 : -move、-delete、-files、-openforwrite、-includeSnapshots、-list-corruptfileblocks、-blocks、-locations、-racks、-storagepolicies、-blockld。 





具体 参数 功能 对 应 的 逻辑 代码 会 在 下 文 的 分 析 中 详细 地 讲述 。 


4.1.2 fsck 过 程 调用 





fsck 过 程 的 调用 指 的 是 从 终端 窗口 输入 到 最 终 fsck 在 HDFS 内 部 执行 完毕 的 整个 过 程 。 中 间 经 过 的 类 其 实 不 多 ， 图 4-1 为 fsck 执 行 过 程 。 











invoking invoking 


FsckServlet NElalslilele ls :Ie ,4 











图 4-1 ”fsck 过 程 调用 图 
































上 图 的 调用 形式 可 以 说 是 三 层 调用 结构 。DFSck 是 暴露 在 最 外 层 的 类 ， 下 面 再 来 梳理 一 下 中 间 的 过 程 : 

















1) 输入 fsck<path> 直 接 调 用 到 的 是 类 DFSck。DFSck 内 部 会 以 http 请 求 的 方式 ， 根 据 参数 构造 URL 请 求 地 址 ， 发 送 请 求 到 下 一 个 处 理 对 象 中 。 








2) 下 一 个 处 理 对 象 是 FsckServlet。FsckServlet 相 当 于 一 个 过 渡 者 的 角色 ， 用 于 马上 调用 真正 操作 类 NamenodeFsck。 




















3) NamenodeFsck 会 取出 请 求 参 数 ， 然 后 在 HDFS 内 部 做 真正 的 fsck 检 测 操作 。 


4.1.3 ”fsck 原 理 分 析 





fsck 原 理 分 析 将 会 展示 更 加 细致 的 fsck 过 程 调用 。 根 据 上 文 提 到 的 三 层 调用 ， 我 们 将 此 过 程 分 为 三 个 分 析 部 分 。 





1.DFSck 请 求 构造 


我 们 可 以 把 此 类 比 成 DFSAdmin。 首 先 介绍 命令 输入 处 理 入 口 方法 : 








public int run(final String[] args) throws IOException { 


if (args.length == 0) { 
printUsage (System.err); 
return -1; 


} 


try { 
return UserGroupInformation.getCurrentUser () .doAs( 
new PrivilegedExceptionAction<Integer>() { 
QOverride 
public Integer run() throws Exception { 
// 传 入 输入 的 参数 进行 命令 的 执行 
return doWork (args); 
} 
1); 
} catch (InterruptedException e) { 
throw new IOException (e); 
} 
i 





在 doWork 方 法 中 ， 进 行 了 参数 的 判别 分 类 ， 同 时 开始 构造 不 同 的 参数 请 求 。 





private int doWork(final String[] args) throws IOException { 
final StringBuilder Url = new StringBuilder (); 


url.append ("/fsck?ugi=") .append (ugi .getShortUserName () ) 7 
String dir = null; 
boolean doListCorruptFileBlocks = false; 
// 遍历 参数 ， 进 行 相关 参数 的 请 求 设置 
for (int idx = 0; idx < args.length; idx++) { 


if (args [idx] .equals("-move")) { url.append("&move=1") 7 } 

else if (args [idqx] .equals("-delete")) { url.append("&delete=1"); } 

else if (args [idqx] .equals ("-files")) { url.append("g&files=1"); } 

else if (args [idqx] .equals ("-openforwrite")) { url.append("&openforwrite=1"); } 

else if (args [idqx] .equals ("-blocks")) { url.append("g&blocks=1"); } 

else if (args [idqx] .equals("-locations")) { url.append("&locations=1"); } 

else if (args [idqx] .equals("-racks")) { url.append("g&racks=1"); } 

else if (args[idx] .equals("-storagepolicies")) { url.append ("&storagepolicies=1"); 
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不 同类 型 的 参数 后 面 接 的 参数 值 不 一 定 相同 ， 比 如 -blockld 后 面 会 跟 连 续 的 块 1d。 
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} else if (args [idx] .equals ("-blockId") ) { 
StringBuilder sb = new StringBuilder(); 
idx++; 
while(idx < args.length && !args[idx] .startsWith (" 
sb.append (args [idx] ); 
sb.append (™ "); 
idxt++» 
* 
url.append ("&blockId=") .append (URLENncoder .encode (sb.tostring(), "UTF-8")); 
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请 求 ur 构造 好 之 后 ， 发 起 请 求 : 





URL path = new URL (Url1.toString()) 7 
URLConnection connection; 
try { 
connection = connectionFactory.openConnection (path, isSpnegoEnabled); 
} catch (AuthenticationException e) { 
throw new IOException (e); 


} 





随后 获取 响应 回复 ， 直 接 输出 到 终端 上 。 








InPutStream stream = connection.getIinputStream(); 
BufferedReader input = new BufferedReader (new InputStreamReader (stream, "UTF-8")); 
String line = null; 
String lastLine = null; 


int errCode = -1? 
try { 
while ((line = input.readLine()) != null) { 


out.println (line); 
lastLine = line; 


} 
} finally { 
input.close(); 


























到 此 ，DFSck 最 外 层 的 调用 过 程 就 走 通 了 。 








2.FsckServlet 请 求 处 理 


上 个 步骤 中 url 请 求 会 转 到 FsckServlet 中 处 理 ，FsckServlet 类 似 代理 人 的 角色 ， 紧 接着 调用 NamenodeFsck 进 行 处 理 : 





// doGet 处 理 fsck 的 请 求 
QOverride 
public void doGet (HttpServletRequest request, HttpServletResponse response 
) throws IOException { 
@SuppressWarnings ("unchecked") 
final Map<String,String[]> pmap = request.getParameterMap (); 
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final UserGroupInformation ugi = getUGI (request, conf); 
trey 4 
ugi.doAs (new PrivilegedExceptionAction<Object>() { 
QOverride 
public Object run() throws Exception { 
NameNode nn = NameNodeHttpServer.getNameNodeFromContext (context); 


final FSNamesystem namesystem = nn.getNamesystem(); 
final BlockManager bm = namesystem.getBlockManager (); 
final int totalDatanodes = 
namesystem.getNumberOfDatanodes (DatanodeReportType .LIVE); 
// 调用 NamenodeFsck 的 fsck 方 法 进行 处 理 
new NamenodeFsck (conf, nn, 
bm.getDatanodeManager () .getNetworkTopology(), pmap, out, 
totalDatanodes, remoteAddress) .fsck(); 


return null; 
} 
Hs 
} catch (InterruptedException e) { 
response.sendError (400, e.getMessage()); 
} 
} 





3.NamenodeFsck 的 fsck 处 理 








最 后 一 个 步骤 调 








的 是 NamenodeFsck 的 fsck 方 法 。 在 进入 这 个 方法 之 前 ， 先 了 解 这 个 类 内 部 的 一 些 关 键 变量 : 





private String lostFound = null; 
private boolean lfInited = false; 
private boolean lfIinitedok = false; 


// 显示 文件 标识 


private boolean showFiles = false; 


// 显示 已 打 天 





的 文件 标识 


Private boolean showOpenFiles = false; 


// 显示 块 信息 标识 


private boolean showBlocks = false; 

// 显示 位 置信 息 标 识 

private boolean showLocations = false; 

// 显示 机 架 信息 标识 

private boolean showRacks = false; 

// 显示 存储 策略 标识 

private boolean showStoragePolcies = false; 

// 显示 损坏 文件 标识 

private boolean showCorruptFileBlocks = false; 





这 些 布尔 类 型 的 变量 对 应 的 就 是 fsck 帮 助 信息 中 所 展示 的 各 个 参数 。fsck 方 法 内 部 的 处 理 顺 序 看 起 来 有 点 乱 ， 为 了 便于 大 家 理解 ， 这 里 对 指定 参数 进行 指定 分 析 。 





第 一 个 参数 方法 -list-corruptfileblocks， 展 示 丢 失 /损坏 的 块 。 





if (showCorruptFileBlocks) { 
listCorruptFileBlocks (); 


return; 


} 











调用 到 同名 方法 listCorruptFileBlocks。 











Private void listCorruptFileBlocks() throws IOException { 
Collection<FSNamesystem.CorruptFileBlockInfo> corruptFiles = namenode. 
getNamesystem() .listCorruptFileBlocks (path, currentCookie); 
int numCorruptFiles = corruptriles.size(); 
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out .Println ("Cookie:\t" + currentCookie[0]); 
for (FSNamesystem.CorruptFileBlockInfo c : corruptFiles) { 
out.println(c.tostring()); 


} 


out.println("\n\nThe filesystem under path '" + path + "' has " + filler 
+ " CORRUPT files"); 


out.println(); 














此 方法 最 终 会 调 


块 对 象 : 








到 FSNamesystem 的 listCorruptFileBlocks 方 法 ， 注 意 这 里 还 传 入 了 一 个 特别 的 参数 currentCookie， 这 个 参数 的 作 | 

















比较 巧妙 。 进 入 FSNamesystem 的 方法 ， 首 先 初始 化 损坏 文件 





ArrayList<CorruptFileBlockInfo> corruptFiles = new ArrayList<CorruptFileBlockInfo>(); 





方法 返回 的 对 象 即 为 损坏 文件 块 对 象 。 


然后 进入 关键 的 损坏 文件 的 判断 逻辑 : 





// 做 一 个 快速 的 检查 ， 如 果 当 前 没有 损坏 的 文件 ， 无 须 申请 锁 操 作 
if (blockManager.getMissingBlocksCount() == 0) { 
if (cookieTab[0] == null) { 
CookieTab [0] = String.valueOf (getIntCookie (cookieTab[0])); 


} 


if (LOG.isDebugEnabled()) { 
LOG.debug ("there are no corrupt file blocks."); 


} 


return corruptFiles; 


} 





blockManager 的 getMissingBlocksCount 方 法 取 的 就 是 损坏 块 队列 的 大 小 : 





public long getMissingBlocksCount () { 
// 此 处 实际 返回 的 是 损坏 块 的 数量 


return this.neededReplications.getCorruptBlockSize(); 


} 





如 果 此 方法 的 Count 返 








回 





值 有 值 ， 即 大 于 0， 则 方法 执行 继续 : 








// 获取 损坏 块 的 块 迭代 器 

final Iterator<Block> blkIterator = blockManager.getCorruptReplicaBlockIterator (); 
// 取出 cookie 值 作为 标记 位 ， 跳 过 标记 下 标 之 前 的 文件 ， 代 表 已 经 浏览 过 

int skip = getIntCookie (cookieTab[0]) 7 


for (int i 


0; i < skip && blkIterator.hasNext (); i++) { 


blkIterator.next (); 


} 


while (blkIterator.hasNext()) { 
Block blk = blkIterator.next (); 
final INode inode = (INode)blockManager.getBlockCollection (blk); 
// 更 新 skip 跳 过 值 


SkipP++7 


if (inode != null && blockManager.countNodes (blk) .1iveReplicas() == 0) { 


String SC 


FSDirectory.getFullPathName (inode); 


if (src.startsWith (path)){ 
// 将 损坏 块 文件 信息 加 入 corruptFiles 列 表 内 
corruptFiles.add (new CorruptFileBlockInfo (src, blk)); 


Count++; 


if (count >= DEFAULT MAX CORRUPT FILEBLOCKS RETURNED) 


break; 


} 


} 
// 更 新 cookie 标 记 值 
CookieTab[0] = String.valueOf (skip); 





cookie 的 作 





用 





如 上 注释 所 说 。 获 取 到 此 返回 损坏 文件 列表 后 ， 会 在 上 一 方法 中 将 结果 输出 : 





for (FSNamesystem.CorruptFileBlockInfo C : corruptFiles) 


out.println(c.toString()); 





4.fsck-path 默 认 处 理 方法 


fsck 的 默认 处 理 方法 指 的 是 fsck+ path 的 方法 ， 为 什么 紧 接着 讲 这 个 方法 呢 ? 因为 fsck 的 path 方 法 处 理 也 包括 了 扫描 损坏 块 的 方法 ， 但 是 在 逻辑 上 与 -list-corruptfiles 竟 然 不 一 样 ， 这 一 点 笔者 在 阅读 的 
时 候 ， 会 感到 比较 奇怪 。 首 先 用户 传 入 的 path 会 被 传 入 到 内 部 方法 check 中 处 理 : 




















Result res = new Result (conf) 7 
check (path, file, res); 
out.println (res); 


out.println(" Number of data-nodes:\t\t" + totalDatanodes); 
out.println(" Number of racks:\t\t" + networktopology.getNumOfRacks ()); 











然后 会 进行 目录 、 文 件 的 判断 ， 如 果 是 目录 ， 则 进行 递归 调 

















if (file.isDir()) { 
// 如 果 快 照 目录 包含 此 路 径 ， 则 递归 快照 目录 下 的 path 
if (snapshottableDirs != null && snapshottableDirs.contains (path)) { 
String snapshotPath = (path.endsWith (Path.SEPARATOR) ? path : path 
+ Path.SEPARATOR) 
+ HdfsConstants.DOT SNAPSHOT DIR; 
HdfsFileStatus snapshotFileInfo = namenode.getRpcServer () .getFileInfo( 
snapshotPath); 
Check (snapshotPath, snapshotFileInfo, res); 
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dof{ 
assert lastReturnedName != null; 
thisListing = namenode.getRpcServer () .getListing( 
path, lastReturnedName, false); 
if (thisListing == null) { 
return; 
} 
HdfsFileStatus [] files = thisListing.getPartialListing(); 
// 如 果 此 path 是 目录 的 话 ， 递 归 遍历 此 path 的 子 文件 
for (int i = 0; i < files.length; i++) { 
check (path, files[i], res); 
} 
lastReturnedName = thisListing.getLastName (); 
} while (thisListing.hasMore()); 
return; 


} 


在 接 下 来 分 析 检 测 文件 时 ， 会 进行 相应 指标 统计 值 的 更 新 。 





isOpen = blocks.isUnderConstruction () 7 
if (isOpen && !showOpenFiles) { 
// 更 新 正在 被 写 入 文件 的 一 些 指标 信息 ， 供 不 同 fsck 的 参数 使 用 
res.totalOpenFilesSize += fileLen; 
res.totalOpenFilesBlocks += blocks.]locatedBlockCount (); 
res .totalOpenFiles++7 
return; 


' 

// 更 新 文件 块 相关 的 信息 

res.totalFilest+; 

res.totalSize += fileLen; 

res.totalBlocks += blocks.locatedBlockCount (); 





下 面 是 fsck 默 认 的 损坏 块 的 判断 逻辑 : 
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for (LocatedBlock lBlk : blocks.getLocatedBlocks()) { 加 

ExtendedBlock block = lBlk.getBlock(); 

boolean isCorrupt = lBlk.isCorrupt () 7 

String blkName = block.toString() 7 
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这 里 利用 了 LocatedBlock 内 部 的 isCorrupt 的 方法 ， 然 后 进行 corrupt 计 数 累加 : 








// 检查 块 是 否 损坏 了 
if (isCorrupt) { 
Corruptt++; 
res.corruptBlocks++; 
out.print ("\n" + path + ": CORRUPT blockpool " + block.getBlockPoolId() + 
" block " + block.getBlockName ()+"\n"); 





在 这 里 ， 丢 失 块 的 判断 逻辑 是 独立 于 损坏 块 的 。 


// 重新 进行 块 副本 数 的 统计 
NumberReplicas numberReplicas = 

namenode .getNamesystem() .getBlockManager () .countNodes (block.getLocalBlock ()); 
// 获取 存在 的 副本 数 


int liveReplicas = numberReplicas.liveReplicas(); 


// 如 果 当 前 副本 数 为 0， 则 表明 是 丢失 块 
if (liveReplicas == 0) { 
report .append (" MISSING!"); 
res.addMissing (block.toString ()，block.getNumBytes ()) 7 
missing++; 
missize += block.getNumBytes (); 
} else { 








回顾 以 上 check 方 法 中 的 这 两 类 块 判 断 逻 辑 。 对 于 第 二 个 丢失 块 的 判断 逻辑 ， 笔 者 认为 是 没有 问题 的 ， 但 是 第 一 个 损坏 块 的 判断 逻辑 可 能 有 点 问题 ， 尽 管 说 LocatedBlock 提 供 了 内 部 方法 
isCorrupt， 但 是 在 查询 isCorrupt 的 调用 处 时 发 现 绝 大 多 数 情况 下 都 是 false 参 数 默认 传 入 的 ， 而 且 在 数据 实时 性 和 有 效 性 上 ， 这 个 方法 没有 -list-corruptfiles 参 数 来 得 快 与 准 (笔者 个 人 观点 ， 可 能 理解 不 
同 ) 。 因 为 -list-corruptfiles 是 直接 从 FSNamesystem 类 中 获取 的 ， 从 大 的 层面 来 说 ， 代 表 的 已 经 是 最 新 损坏 块 数据 的 信息 了 。 


























5.fsck-delete/-move 








这 两 个 命令 的 作用 是 找到 损坏 块 之 后 ， 做 进一步 处 理 ， 就 是 下 面 两 行 代码 所 控制 的 路 径 : 











http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} else { 
// 如 果 输 入 了 -move 参 数 ， 则 将 块 移 至 lost+found 目 录 下 


if (doMove) copyBlocksToLostFound (parent, file, blocks); 
// 如 果 输 入 了 -delete 参 数 ， 则 删除 指定 路 径 下 损坏 的 文件 块 
if (doDelete) deleteCorruptedFile (path); 


下 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
























































LostFound 指 的 是 /lost+found 目 录 ，-move 参 数 会 将 损坏 块 文件 移 至 此 目录 下 ， 而 -delete 则 会 调用 直接 删除 文件 的 方法 。 
private void deleteCorruptedFile (String path) { 
try { 

// 调用 NameNode 删 除 文件 的 方法 

namenode .getRpcServer () .delete (path, true); 

LOG.info("Fsck: deleted corrupt file "+ path); 
} catch (Exception e) { 

LOG.error ("Fsck: error deleting corrupted file " + path, e); 

internalError = true; 

于 
进行 清 因为 元 数据 虽然 存在 ， 但 是 真实 数据 已 经 损坏 ， 读 写 操 




















两 个 命令 在 清理 损坏 数据 的 场景 中 比较 有 





作 必 然 会 抛 出 异常 。 


6.fsck 辅 助 显示 参数 


以 上 几 个 是 fsck 的 主要 参数 ， 下 面 是 一 些 辅助 的 次 要 参数 。 


。 如 果 集群 中 存在 大 量 损坏 块 数据 的 情况 ， 不 及 时 进 


行 衣 





， 会 出 现 大 量 客户 端 读 写 操作 的 失败 ， 














* ~locations/-racks 


if (showLocations || showRacks) { 


StringBuilder sb = new StringBuilder("["); 
for (int j = 0; j < locs. length; a { 
if (3 > 0) { sb. en 人 时 下 


// 大 末末 十 从 出 训 加 和 向 ， 基 引 办 
if (showRacks) 

sb.append (NodeBase .getPath (locs[j])) 
else 

sb.append (locs[j]); 


sb.append(']'); 
report .append(" " + sb.toString()); 
} 


* -storagepolicies 


if (this.showStoragePolcies) { 
storageTypeSummary = new StoragePolicySummary( 


namenode .getNamesystem() .getBlockManager () .getStoragePolicies ()); 


} 


由 //wuw.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 


出 存储 策略 信息 
if (this. showStoragePolcies) { 
out .Print (storageTYyPeSummary.toString () ) 7 
} 


* -includeSnapshots 


此 参数 会 获取 NameNode 快 照 中 的 目录 信息 


if (snapshottableDirs != null) { 
SnapshottableDirectoryStatus[] snapshotDirs = 
.getSnapshottableDirListing(); 
if (snapshotDirs != null) { 
for (SnapshottableDirectoryStatus dir : snapshotDirs) { 
snapshottableDirs.add (dir.getFullPath () .tostring()); 
} 
} 
} 


namenode .getRpcServer () 











端 ， 最 后 是 总 


结 报告 的 输出 ， 如 下 所 示 : 





在 这 些 参数 执行 期 间 ， 会 伴随 着 结果 的 输出 ， 所 以 你 将 会 看 到 路 径 的 信息 被 展示 到 终端 
Total size: 88.13 KB 

Total dirs: 14 

Total files: 20 

Total symlinks: 0 

Total blocks (validated): 20 (avg. block size 4512 B) 


大大 突 册 闪 因 六 类 次 六 突 六 六 六 六 类 六 央 关 次 六 大大 次 类 六 六 类 次 商 六 


UNDER MIN REPL'D BLOCKS: 


20 (100.0 $%) 
dfs.namenode.replication.min: 1 


CORRUPT FILES: 20 

MISSING BLOCKS: 20 

MISSING SIZE: 88.13 KB 
CORRUPT BLOCKS: 20 


六 大 六 次 次 六 闪 交 类 大 大 六 次 大 闪 次 闪 六 次 关 类 交 大 六 次 六 六 次 六 炎 闪 
Minimally replicated blocks: 
Over-replicated blocks: .te 
Under-replicated blocks: 0 ( 
Mis-replicated blocks : 0 
Default replication factor: 0 
Average block replication: 
Corrupt blocks: 

Missing replicas: 0 

Number of data-nodes: 0 

Number of racks: 0 

FSCK ended at Tue Mar 29 11:10:33 CST 2016 in 10 milliseconds 


The filesystem under path '/' is CORRUPT 





NamenodeFsck 的 处 理 过 


程 和 参数 控制 如 上 内 容 所 述 ， 方 法 主要 集中 在 fsck 和 check 的 两 个 方法 内 ， 并 根据 所 选 参数 选择 性 地 输出 中 间 结 








图 4-2 为 fsck 的 执行 逻辑 。 













showBlocks showStoragePolcies includeSnapshots showCorruptFileBlocks 












showFiles doDelete 


showOpenFiles showLocations showRacks 


4-2 fsck 检测 执行 逻辑 


























4.1.4 ”fsck 使 用 场景 


fsck 块 检查 命令 有 许多 使 用 场景 ， 下 面 是 两 类 比较 常见 的 使 用 场景。 























第 一 类 场景 ， 损 坏 块 、 丢 失 块 的 检查 与 处 理 。 通 过 fsck 命 令 附 带 上 目标 检查 路 径 参 数 能 够 得 到 详细 的 检测 结果 。 如 果 检 测 出 有 丢失 或 损坏 的 块 ， 通 过 -delete 参 数 可 以 直接 进行 删除 ， 防 止 丢 失 的 文件 块 
造成 程序 执行 的 异常 。 


第 二 类 场景 ， 块 信息 的 查询 。 通 过 fsck 的 -files、-bloks 等 参数 可 以 很 详细 地 得 到 块 存储 位 置 等 信息 ， 甚 至 还 能 通过 块 1d 查 询 该 块 对 应 的 位 置信 息 。 











4.2 ”HDFS 如 何 检测 并 删除 多 余 副 本 块 


在 HDFS 中 ， 每 时 每 刻 都 在 进行 着 大 量 块 的 创建 和 删除 操作 ， 从 而 使 得 集群 中 维护 的 都 是 有 效 的 数据 ， 而 在 块 删除 的 场景 中 ， 有 一 类 情况 比较 特殊 : 删除 多 余 的 副本 块 。 当 一 个 文件 块 的 现 有 副本 数 超过 
它 的 期 望 副本 数 ， 多 出 来 的 那些 块 即 “ 多 余 的 副本 块 ”。 多 余 副 本 块 的 出 现 往往 发 生 在 某 些 特殊 的 场合 ， 所 以 本 节 要 讲述 的 主要 内 容 有 : 第 一 ，HDFS 如 何 检测 这 些 多 余 副 本 块 ; 第 二 ， 检 测 出 来 了 如 何 进行 
删除 ;第 三 ， 删 除 的 逻辑 策略 。 


4.2.1 多 余 副 本 块 以 及 发 生 的 场景 


下 面 举例 说 明 多 余 副 本 块 : 假设 集群 中 有 3 个 A 副 本 块 ， 满 足 标准 的 三 副本 策略 ， 但 是 发 生 了 某 种 操作 后 ，A 副 本 块 突然 变 为 了 5 个 ， 为 了 达到 副本 块 的 标准 块 数 3 个 ， 系 统 会 进行 多 余 2 块 副本 的 清除 动 
作 ， 而 这 个 清除 动作 就 是 本 节 所 要 重点 讲述 的 。 多 余 副 本 块 的 现象 是 比较 好 理解 的 ， 但 是 到 底 有 哪些 潜在 的 原因 或 条 件 会 触发 多 余 副 本 块 的 发 生 呢 (在 此 指 的 是 HDFS 中 ) ? 笔者 通过 对 HDFS 源 码 的 阅读 ， 











“ ReCommission 节 点 重新 上 线 。 这 类 操作 是 运 维 操作 引起 的 ， 节 点 下 线 操作 会 导致 大 量 此 节点 的 块 在 集群 中 被 大 量 拷贝 ， 一 旦 此 节点 取消 下 线 ， 之 前 已 拷贝 的 大 量 块 会 成 为 多 余 的 副本 块 。 
“ 人 为 重新 设置 块 副本 数 。 还 是 以 A 副本 块 举例 ，A 副 本 块 当前 满足 标准 副本 数 3 个 ， 此 时 用 户 张 三 通 过 使 用 HDFS 中 设置 副本 数 API， 人 为 设置 A 副本 数 为 1 个， 也 会 造成 A 副本 数 多 于 期 望 值 2 个 的 情况 。 
“ 新 添加 的 块 记录 在 系统 中 被 丢失 。 这 种 情况 相对 于 前 两 种 的 情况 ， 是 内 部 因素 造成 的 。 这 些 新 添加 的 丢失 的 块 记 录 会 在 BlockManager 中 再 次 扫描 检测 ， 防 止 出 现 多 余 副 本 的 现象 。 
以 上 3 种 情况 是 可 能 发 生 多 余 副 本 块 的 潜在 场景 。 至 于 这 三 种 情况 是 如 何 一 步 步 调 用 处 理 多 余 副 本 块 的 过 程 ， 下 文 会 一 一 进行 讲述 ， 先 来 看 多 余 副 本 块 是 如 何 被 选 出 并 处 理 的 。 
4.2.2 OverReplication 多 余 副 本 块 处 理 
多 余 副 本 块 的 处 理 分 为 两 个 子 过 程 : 
“多余 副 本 块 的 选 出 
“多余 副 本 块 的 处 理 
我 们 从 源码 中 寻找 答案 ， 首 先是 副本 块 的 选 出 。 
1. 多 余 副 本 块 的 选择 


进入 BlockManager 的 processOverReplicatedBlock 方 法 ， 此 方法 名 已 经 表明 了 其 操作 的 本 意 。 





JR 
* 寻找 是 否 有 节点 包含 了 多 余 的 副本 块 ， 如 果 确 实 包含 了 ， 则 调用 
* chooseExcessReplicates 方 法 标记 它们 到 对 象 excessReplicateMap 中 。 
vy 

private void processOverReplicatedBlock (final Block block, final short replication, final DatanodeDescriptor addedNode, DatanodeDescriptor delNodeHint) { 














此 方法 中 注释 的 意思 是 找 出 存在 多 余 副 本 的 节点 ， 如 果 它们 是 ， 则 调用 chooseExcess-Replicates 方 法 并 标记 它们 ， 并 加 入 到 excessReplicateMap 对 象 中 。 下 面 进行 细节 的 处 理 : 











// 节点 列表 变量 的 声明 
Collection<DatanodeStorageInfo> nonExcess = new ArrayList<DatanodeStorageInfo>(); 
// 从 corruptReplicas 变 量 中 获取 是 否 存 在 包含 坏 块 的 节点 


Collection<DatanodeDescriptor> corruptNodes = corruptReplicas.getNodes (block); 





继续 后 面 的 处 理 : 





// 遍历 此 过 量 副 本 块 所 在 的 节点 列表 

for (DatanodeStorageInfo storage : blocksMap.getStorages (block, State.NORMAL)) { 
final DatanodeDescriptor cur = storage.getDatanodeDescriptor(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
LightWeightLinkedSet<Block> excessBlocks = excessReplicateMap.get (cur 


getDatanodeUuid() ) 7 
2 如 果 在 当前 前 多 余 副本 对 象 excessReplicateMap 中 不 存在 
if (excessBlocks == null || !excessBlocks .contains (block)) { 
// 并 且 所 在 节点 不 是 已 下 线 或 下 线 中 的 节点 
if (!cur.isDecommissionInProgress() && !cur.isDecommissioned()) { 
// 并 且 这 个 副本 块 不 是 损坏 的 副本 块 
// exclude corrupt i 
if (corruptNodes == null 11 !corruptNodes.contains (cur)) { 
// 将 此 多 余 副 本 块 的 一 个 所 在 节点 加 入 候选 节点 列表 中 
nonExcess.add (storage) 
} 
} 
} 
} 














从 这 里 可 以 看 出 nonExcess 对 象 其 实 是 一 个 候选 节点 的 概念 ， 将 块 副本 所 在 的 节点 列表 进行 多 种 条 件 的 再 判断 和 剔除 。 最 后 再 调用 选择 最 终 多 余 副 本 块 节点 的 方法 : 











ChooseExcessReplicates (nonExcess, block, replication, 
addedNode, delNodeHint, blockplacement); 





进入 chooseExcessReplicates 方 法 : 





// 首先 会 形成 机 架 对 DataNode 节 点 的 映射 关系 图 
BlockCollection bc = getBlockCollection (b); 
final BlockStoragePolicy storagePolicy = storagePolicySuite.getPolicy (bc.getStoragePolicyID()); 
final List<StorageType> excessTypes = storagePolicy.chooseExcess( 
replication, DatanodeStorageInfo.toStorageTypes (nonExcess)); 
// 初始 化 机 架 -> 节 点 列表 映射 图 对 象 
final Map<String, List<DatanodeStorageInfo>> rackMap 
= new HashMap<String, List<DatanodeStorageInfo>>(); 
// 超过 一 个 本 本 数 的 节点 区 家 
final List<DatanodeStorageInfo> moreThanOne = new ArrayList<DatanodeStorageInfo>(); 
/ 恰好 一 个 副本 数 的 节点 列表 


final List<DatanodeStorageInfo> exactlyOne = new ArrayList<DatanodeStorageInfo> () 7 




















为 什么 这 里 要 划分 出 不 同 的 节点 列表 呢 ? 因 为 在 这 里 设计 者 做 了 优先 选择 ， 在 同样 拥有 多 余 副本 块 的 节点 列表 中 ， 优 先 选 
理解 ， 因 为 上 面 的 多 余 副本 数 更 多 ， 这 里 当然 要 先 从 多 的 开始 删 。 











择 节 点 中 副本 数 多 于 一 个 的 ， 其 次 是 副本 数 恰好 为 一 个 的 节点 。 这 个 设计 很 好 





// 节点 划分 成 对 应 两 个 集合 本 

// moreThanOne 包 含 了 此 机 架 下 拥有 一 个 以 上 副本 的 节点 

// exactlyOne 则 包含 了 余下 的 节点 

replicator.splitNodesWithRack (nonExcess, rackMap, moreThanOne, exactlyOne); 





进入 划分 方法 : 





public void splitNodesWithRack( 
final Iterable<DatanodeStorageInfo> storages, 
final Map<String, List<DatanodeStorageInfo>> rackMap, 
final List<DatanodeStorageInfo> moreThanOne, 
final List<DatanodeStorageInfo> exactlyOne) { 
// 遍历 候选 节点 列表 ， 形 成 机 架 -> 节 点 列表 的 对 应 关系 
for (DatanodeStorageInfo s: storages) { 
final String rackName = getRack(s.getDatanodeDescriptor ()); 
List<DatanodeStorageInfo> storageList = rackMap.get (rackName); 
if (storageList == null) { 
storageList = new ArrayList<DatanodeStorageInfo>(); 
rackMap.put (rackName, storageList); 
} 
storageList.add(s); 
} 





下 面 是 划分 算法 : 





// 拆 分 节点 到 两 个 集合 
er a St : rackMap.values()) { 
if (storageList. Size 











// 如 果 机 架 中 对 应 节 和 而 本性 信和 位 置 数量 只 有 一 个 ， 则 表明 节点 上 副本 数 就 为 1， 加 入 exact1lyOne 集 合 内 ， 否 则 就 为 多 个 ， 此 时 加 入 集合 moreThanone 


exactlyOne.add (storageList .get (0)); 
} else { 
moreThanOne.addAll (storageList); 
} 
} 





DatanodeStoragelnfo 类 表示 的 是 DataNode 中 存放 数据 的 目录 位 置信 息 。 如 果 一 个 storageList 的 大 小 为 1， 说 明 此 节点 




















内 只 有 一 个 存储 此 副本 的 位 置信 息 ， 间 接 说 明 此 节点 内 只 有 一 个 此 副本 块 。 于 








是 在 这 段 代码 过 后 ， 节 点 组 就 被 分 为 了 两 大 类 : exactlyOne 和 moreThanOne。 至 此 chooseExcessReplicates 的 上 半 段 代码 执行 完 


毕 ， 接 下 来 看 下 半 段 代码 的 执行 过 程 





// 选择 一 个 待 删除 的 节点 ， 会 偏向 qelNodeHintStorage 的 节点 
// 否则 会 从 节点 列表 中 选 出 一 个 可 用 空间 最 小 的 节点 
boolean firstone = true; 
final DatanodeStorageInfo delNodeHintStorage 
= DatanodeStorageInfo.getDatanodeStorageInfo (nonExcess, delNodeHint); 
final DatanodeStorageInfo addedNodeStorage 
= DatanodeStorageInfo.getDatanodeStorageInfo (nonExcess, addedNode); 





上 面 两 行 注释 传达 出 两 个 意思 : 


“ 可 以 直接 传 入 要 删除 的 节点 ， 如 果 条 件 允 许 ， 则 优先 选择 传 入 的 delHint 节 点 。 


“ 在 每 个 节点 的 内 部 列表 中 ， 优 选 选 择 出 可 用 空间 最 少 的。 这 个 也 好 理解 ， 在 同样 拥有 过 量 副 本 数 的 节点 列表 中 ， 选 择 可 


用 空间 尽 可 能 少 的 ， 这 样 可 以 快速 地 释放 出 更 多 的 可 用 空间 。 





// 如 果 目 前 多 余 副 本 所 在 节点 数 大 于 标准 副本 数 ， 则 进行 循环 移 除 
while (nonExcess.size() - replication > 0) { 
final DatanodeStorageInfo cur; 
// 判断 是 否 可 以 使 用 delNodeHintStorage 节 点 进行 代替 
if (useDelHint (firstOne, delNodeHintStorage, addedNodeStorage, 
moreThanOne, excessTypes)) { 
cur = delNodeHintStorage; 
} else { 
否则 进行 常规 的 节点 选择 
cur = replicator.chooseReplicaToDelete (bc, b, replication, 
moreThanOne, exactlyOne, excessTypes); 





























判断 是 否 可 以 使 用 delNodeHintStorage 节 点 的 处 理 逻 辑 这 里 先 略 过 ， 主 要 看 一 下 BlockPlacementpPolicy 的 chooseReplicaToDelete 方 法 ， 这 个 分 支 处 理 才 是 最 经 常用 到 的 处 理 方式 。 





























// 选择 的 节点 要 么 是 心跳 时 间 最 老 的 或 者 是 可 用 空间 最 少 的 
// 从 两 个 集合 中 按 顺 序 遍历 节点 


for (DatanodeStorageInfo storage : pickupReplicaSet (first, second)) { 
if (!excessTypes.contains (storage.getStorageType())) { 
continue; 


} 





这 里 的 first 和 second 分 别 代表 拥有 多 余 一 个 副本 数 和 恰好 拥有 一 个 副本 数 的 节点 集合 ， 此 处 优先 选择 前 者 ， 节 点 集合 选择 逻辑 如 下 : 





protected Collection<DatanodeStorageInfo> pickupReplicaSet ( 
Collection<DatanodeStorageInfo> first, 
Collection<DatanodeStorageInfo> second) { 
return first.isEmpty() ? second : first; 
} 





在 节点 列表 每 次 的 迭代 循环 中 会 进行 下 面 两 个 指标 的 比较 : 





// 进行 心跳 时 间 的 对 比 

if (lastHeartbeat < oldestHeartbeat) { 
oldestHeartbeat = lastHeartbeat; 
oldestHeartbeatStorage = storage; 


} 

// 进行 可 用 空间 的 对 比 

if (minSpace > free) { 
minSpace = free; 
IminSpaceStorage = storage; 

} 





然后 进行 选择 ， 优 先 选择 心跳 时 间 最 老 的 : 





final DatanodeStorageInfo storage; 
if (oldestHeartbeatStorage != null) { 
storage = oldestHeartbeatStorage; 


} else if (minSpaceStorage != null) { 
storage = minSpaceStorage; 
} else { 


return null; 





然后 进行 下 面 两 个 操作 : 





// 重新 进行 TackMap 对 象 关系 的 调整 

replicator.adj 0 (rackMap, moreThanOne, 
exactlyOne, 

// 将 选 出 的 节 四 点 列表 中 移 除 


nonExcess.remove (cur); 








可 以 说 到 了 这 里 ， 多 余 副 本 块 所 在 节点 就 被 选 出 了 。 


2. 多 余 副 本 块 的 处 理 


此 时 ， 多 余 副 本 块 的 处 理 就 显得 比较 简洁 了 ， 反 正 目标 对 象 以 及 所 在 节点 已 经 被 找到 了 ， 加 入 到 相应 的 对 象 中 即 可 : 








// 加 入 到 excessReplicateMap 对 象 中 
addToExcessReplicate (Cur.getDatanodeDescriptor () b); 


// 将 此 节点 上 的 多 余 副 本 块 加 入 到 无 效 节点 中 
addToInvalidates (b, cur.getDatanodeDescriptor()); 





加 入 到 invalidates 无 效 块 列表 后 不 久 ， 此 块 就 将 被 清除 。 


4.2.3 ”多 余 副 本 块 清除 的 场景 调用 


场景 














新 回 到 上 文 提 到 过 的 多 余 副 本 块 的 三 大 调用 场景 。 通 过 查看 chooseExcessReplicates 方 法 的 调用 就 可 以 找到 这 些 场景 ， 如 图 4-3 所 示 。 


中 | 





殉国 chooseExcessReplicates(Collection<DatanodeStoragelnfo>， Block, short, DatanodeDes' 
下 回 processOverReplicatedBlock(Block, short, DatanodeDescriptor, DatanodeDescriptor) 
Pp 男 addStoredBlock(BlocklnfoContiguous, DatanodeStoragelnfo, DatanodeDescriptor, 


> © checkReplication(BlockCollection) : void - org.apache.hadoop.hdfs.server.blockmsz 
Pp 男 processMisReplicatedBlock(BlockinfoContiguous) : MisReplicationResult - org.ap: 
Pp a processOverReplicatedBlocksOnReCommission(DatanodeDescriptor) : void - org.: 
Pp ©® setReplication(short, short, String, Block...) : void - org.apache.hadoop.hdfs.servel 











图 4-3 ”chooseExcessReplicates 方 法 场景 调用 














针对 上 述 5 种 调用 情况 ， 笔 者 将 其 归纳 为 以 下 4 类 使 用 场景 。 


: ReCommission 重 新 上 线 过 程 











在 DecommissionManager 停 止 下 线 方法 中 调用 了 BlockManager 的 processOverReplicatedBlocksOnReCommission 方 法 来 清除 多 余 副 本 块 。 

















// 对 指定 节点 进行 下 线 操作 


@VisibleForTesting 
Public void stopDecommission (DatanodeDescriptor node) { 
if (node.isDecommissionInProgress() || node.isDecommissioned()) { 


// 更 新 HeartbeatManager 中 的 关于 此 点 的 信息 
hbManager .stopDecommission (node); 
// 删除 之 前 下 线 过 条 中 复制 的 多 余 副 术 
if (node.isAlive()) { 
blockManager .processOverReplicatedBlocksOnReCommission (node); 
i 


// 在 DecommissionManager 中 将 此 节点 移 除 
pendingNodes .remove (node); 
decomNodeBlocks .remove (node); 
} else { 
LOG.trace ("stopDecommission: Node {} in {}, nothing to do." 十 
node, node.getAdminState()); 











下 线 操作 重新 恢复 ， 会 停止 正在 下 线 的 动作 ， 所 以 会 在 这 个 方法 中 进行 调用 。 











场景 2: SetReplication 人 为 设置 副本 数 








人 为 设置 副本 数 是 一 个 主动 因素 ， 调 用 的 方法 如 下 : 











// 为 指定 块 设置 新 的 副本 数 
public void setReplication (final short oldRepl, final short newRepl, 
final String src, final Blockhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... blocks) { 
并 如 打 新 设置 的 吕 不 狼 与 目的 一 样 ， 则 无 无 贫 六 和 任何 操作 ， 直 接 返 回 
if (newRepl 一 oldRepl) { 
return; 


} 


// 更 新 needReplication 内 部 的 块 队列 
for(Block b : blocks) { 
updateNeededReplications (b, 0, newRepl-oldRepl); 


} 
// 当 设 置 的 新 的 副本 数值 比 原 有 的 副本 数值 小 ， 需 要 进行 多 余 副 本 的 清除 操作 
if (oldRepl > newRepl) { 
LOG.info ("Decreasing replication from " + oldRepl + " to " + newRepl 
or "+ See} 
for (Block b : blocks) { 
ProcessOverReplicatedBlock (b, newRepl, null, null); 





} else { // replication factor is increased 
LOG.info("Increasing replication from " + oldRepl + " to " + newRepl 
水 is 











这 个 API 方 法 可 以 被 外 部 的 客户 端 程序 调用 触发 。 











场景 3: 丢失 新 添加 的 块 记录 信息 








当 遍 历 块 的 时 候 ， 有 可 能 会 发 生 丢 失 新 添加 块 记录 的 情况 。 丢 失 新 添加 的 块 信息 会 导致 集群 中 存在 多 余 的 副本 。 


























因为 存在 丢失 块 信息 的 可 能 性 ， 所 以 会 使 用 单独 的 线程 重新 检测 是 否 存在 多 余 副本 的 现象 : 





Private void processMisReplicatesAsync() throws InterruptedException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
while (namesystem.isRunning() && !Thread.currentThread () .isInterrupted () 

int processed = 0; 

namesystem.writeLockInterruptibly (); 

try { 

while (processed < numBlocksPerIteration && blocksItr.hasNext ()) { 

BlockInfoContiguous block = blocksItr.next (); 
// 此 操作 中 会 有 检测 多余 副本 块 的 过 各 
MisReplicationResult res = processMisReplicatedBlock (block); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





场景 4: 其 他 场景 的 检测 























其 他 场景 有 的 时 候 也 会 调用 processOverReplicatedBlock 方 法 ， 但 不 是 外 界 的 因素 导致 ， 而 是 出 于 一 种 谨慎 性 的 考虑 。 比 如 在 addStoredBlock 方 法 中 ， 当 新 添加 的 块 被 加 入 到 blockMap 中 时 ， 会 再 次 
进行 块 的 检测 。 还 有 一 种 情况 是 在 文件 最 终 写 入 完成 的 时 候 ， 也 会 调用 一 次 checkReplication 方 法 ， 以 确认 集群 中 没有 多 余 相 同 块 的 情况 。 这 两 种 情况 的 调用 方法 与 前 面 类 似 ， 这 里 就 不 给 出 具体 的 代码 
了 。 由 此 可 见 ，HDFS 的 设计 者 在 细节 方面 的 处 理 真 的 很 有 






































心 。 








4.3 ”HDFS 数 据 块 的 汇报 与 处 理 





在 HDFS 中 ， 数据 块 的 汇报 与 处 理 过 程 是 十 分 重要 的 环节 ， 因 为 这 关系 到 整个 集群 数据 的 更 新 。DataNode 通 过 心跳 的 方式 ， 将 各 个 类 型 的 数据 块 信息 汇报 给 NameNode， 然 后 接收 NameNode 的 回复 
命令 。 在 NameNode 的 处 理 过 程 中 ， 这 些 块 会 被 分 为 好 几 种 类 型 ， 不 同类 型 的 块 会 对 应 不 同 的 处 理 逻 辑 。 了 解 此 过 程 将 有 助 于 集群 使 用 者 日 后 的 问题 排查 ， 通 过 块 操作 的 输出 记录 来 判断 集群 当前 的 运行 状 
况 。 本 节 主 要 介绍 对 于 各 个 类 型 块 的 处 理 过程 ， 里 面 有 很 多 细节 是 非常 重要 的 。 这 些 块 包括 5 大 类 型 : 新 添加 的 块 、 待 移 除 的 块 、 无 效 的 块 、 损 坏 的 块 以 及 正在 构建 中 的 块 。 



























































4.3.1 块 处 理 的 五 大 类 型 


如 前 言 中 所 述 ，DataNode 的 块 汇报 是 在 心跳 的 过 程 中 进行 的 ， 也 就 是 下 面 所 示 的 代码 : 





// 心跳 汇报 方法 
Private void offerService () throws Exception { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 心跳 汇报 的 循环 执行 
while (shouldRun()) { 
try { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// DataNode 执 行 块 汇报 动作 ， 并 获取 NameNode 返 回 的 回复 命令 
List<DatanodeCommand> cmds = blockReport (); 
// DataNode 处 理 回复 命令 
ProcessCommand (cmds == null ? null : cmds.toArray (new DatanodeCommand[cmds.size()])); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 




















那么 现在 有 个 问题 出 现 了 ，DataNode 在 做 块 汇报 的 时 候 是 每 次 做 全 量 的 汇报 还 是 做 增 量 的 汇报 ”如 果 先 不 看 后 面 的 代码 ， 我 们 当然 认为 做 增 量 的 块 汇报 无 疑 是 更 优 的 选择 。 后 面 的 代码 也 验证 了 我 们 
的 这 个 想法 。 





List<DatanodeCommand> blockReport () throws IOException { 
// 如 果 时 间 已 经 过 期 ， 则 准备 发 送 新 的 块 报告 
final long startTime = scheduler.monotonicNow(); 
if (!scheduler.isBlockReportDue()) { 
return null; 


} 


final ArrayList<DatanodeCommand> cmds = new ArrayList<DatanodeCommand>(); 


// 报告 新 添加 的 块 以 及 删除 的 块 

reportReceivedDeletedBlocks (); 

lastDeletedReport = startTime; 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








在 每 次 块 汇报 的 动作 中 ， 它 将 会 汇报 新 接收 到 的 块 以 及 被 删除 的 块 ， 而 这 两 部 分 的 块 就 是 我 们 所 说 的 增 量 块 的 汇报 ， 英 文 简称 |BR (IncrementBlockReport) 。 倘 若 DataNode 采 用 每 次 全 量 块 汇 报 的 
方式 ，NameNode 和 恐怕 也 承受 不 住 同 时 这 么 多 块 信息 的 汇报 。 在 blockReport 方 法 的 后 续 调 用 过 程 中 ， 最 后 会 调用 到 BlockManager 内 部 的 processReport 块 处 理 方法 ， 如 下 所 示 : 






































// 首次 块 上 报 处 理 方法 
if (storageInfo.getBlockReportCount () 一 
// 首次 块 汇报 操作 ， 首 次 块 的 处 理 将 会 比较 高 效 ， 届 为 汐 类 型 少 
processFirstBlockReport (storageInfo, newReport); 
} else { 
// 正常 块 处 理 方法 
invalidatedBlocks = processReport (storageInfo, newReport); 
} 








这 里 的 块 处 理 方法 分 为 两 类 的 原因 在 于 首次 块 上 报 的 特殊 性 ， 因 为 首次 块 上 报 基本 都 是 新 增 的 有 效 块 ， 在 处 理 效率 上 比 普通 块 的 上 报 要 高 很 多 。 我 们 主要 关注 正常 情况 下 的 块 处 理 过 程 ， 也 就 是 else 钦 
辑 中 的 processReport 方 法 。 这 个 方法 的 注释 很 好 地 概括 了 这 个 方法 所 要 做 的 事情 : 














Private Collection<Block> processReport ( 
final DatanodeStorageInfo storageInfo, 
final BlockListAsLongs report) throws IOException 
// 根据 旧 的 与 新 的 块 报告 之 间 的 不 同 ， 修 改 plock map 中 红 多 下 所 关系 
http://www.hzcourse. com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/ 和 
} 





注释 的 意思 是 根据 新 汇报 上 来 的 块 报告 ， 适 当 进 行 对 应 关系 的 修改 。 假 设 你 之 前 没有 阅读 过 这 部 分 的 代码 ， 可 能 马上 会 联想 到 的 上 报 块 的 类 型 只 有 两 种 ， 一 种 是 新 添加 的 块 addedBlock， 另 一 种 是 需要 
删除 的 块 : removedBlock 或 deletedBlock。 显 然 HDFS 在 设计 的 时 候 不 会 这 么 简单 ，processReport 的 头 几 行 代码 就 表明 了 到 底 有 多 少 种 类 型 的 块 列表 。 








private Collection<Block> processReport ( 
i DatanodeStorageInfo storageInfo, 
nal BlockListAsLongs report) throws IOException 
// 和 与 新 的 块 报告 之 间 的 不 同 ， 修 改 block map 中 多 的 歼 据 关系 
// 新 添加 的 块 
Collection<BlockInfoContiguous> toAdd = new LinkedList<BlockInfoContiguous>(); 
// 待 移 除 的 块 


Collection<Block> toRemove = new TreeSet<Block> () 7 
的 块 


// 无 效 

Collection<Block> toInvalidate = new LinkedList<Block>(); 

// 损坏 的 块 

Collection<BlockToMarkCorrupt> toCorrupt = new LinkedList<BlockToMarkCorrupt>(); 
// 正在 构建 中 的 块 





Collection<StatefulBlockInfo> toUC = new LinkedList<StatefulBlockInfo>(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 这 五 大 类 型 的 块 中 ， 第 一 个 和 最 后 一 个 还 是 比较 好 理解 的 (最 后 一 个 的 toUC 是 toUnderConstruction 的 缩写 ) ， 而 中 间 三 个 则 会 让 人 有 点 混淆 。toRemove、tolnvalidate 和 toCorrput 不 都 表示 这 些 
块 是 待 删 除 的 意思 吗 ? 这 个 问题 在 本 章 后 面 的 内 容 中 会 一 一 进行 分 析 。 图 4-4 为 块 类 型 图 。 











Blocks ToL ist 


toRemove toInvalidate toCorrupt 





图 4-4 处理 块 的 类 型 


4.3.2 toAdd: 新 添加 的 块 


新 添加 的 块 是 指 那 些 新 复制 完 的 块 ， 而 新 复制 完 的 块 的 特征 是 它 的 副本 状态 是 Finalized 的 。 换 名 话说， 这 些 块 在 过 去 的 心跳 时 间 间 隔 内 已 完成 了 块 的 写 操作 ， 并 执行 完了 finalize 确 认 动作 。 但 是 这 里 会 
有 一 个 问题 ，DataNode 在 上 报 块 的 时 候 ， 是 不 细 分 这 些 块 是 损坏 的 或 者 是 正在 构建 中 的 ， 所 以 就 自然 地 移 到 了 NameNode 进 行 这 些 处 理 ， 而 比较 的 方法 则 是 新 的 块 报告 与 当前 维护 的 块 信息 之 间 的 对 比 。 
现 进入 processReport 接 下 来 的 内 部 处 理 逻 辑 中 : 





private Collection<Block> processReport ( 
final DatanodeStorageInfo storageInfo, 
final BlockListAsLongs report) throws IOException 
// 根据 旧 的 与 新 的 块 报告 之 间 的 不 同 ， 修 改 block map 中 红 的 下 所 关系 
Collection<BlockInfoContiguous> toAdd = new LinkedList<BlockInfoContiguous>(); 


Collection<Block> toRemove = new TreeSet<Block> () 7 

Collection<Block> toInvalidate = new LinkedList<Block> () 

Collection<BlockToMarkCorrupt> toCorrupt = new LinkedList<BlockToMarkCorrupt>(); 

Collection<StatefulBlockInfo> toUC = new LinkedList<StatefulBlockInfo>(); 

// 取出 报告 中 存在 差异 的 部 分 

reportDiff (storageInfo, report, 

toAdd, toRemove, toInvalidate, toCorrupt, toUC); 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





reportDiff 方 法 ， 有 点 像 git diff 命 令 ，“ 取 不 同 ” 的 意思 。 在 这 个 方法 中 ， 这 些 列表 都 以 参数 的 形式 传 入 ，reportDiff 方 法 结束 后 ， 这 些 变量 都 将 被 赋值 。 进 入 reportDiff 方 法 : 





Private void reportDiff (DatanodeStorageInfo storageInfo, 
BlockListAsLongs newReport, 





Collection<BlockInfoContiguous> toAdd, 新 添加 的 块 
Collection<Block> toRemove, // 待 移 除 的 块 
Collection<Block> toInvalidatey // 无 效 的 块 
Collection<BlockToMarkCorrupt> toCorrupt, // 损坏 的 块 
Collection<statefulBlockInfo> toUC) { // 正在 构建 中 的 块 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 扫描 处 理 新 的 块 报告 
for (BlockReportReplica iblk : newReport) { 
ReplicaState iState = iblk.getState(); 
BlockInfoContiguous storedBlock = processReportedBlock (storageInfo, 
iblk, iState, toAdd, toInvalidate, toCorrupt, toUC); 


// 移动 块 到 列表 头 部 
if (storedBlock != null && 
(curIndex = storedBlock.findStorageInfo (storageInfo)) >= 0) { 
headIndex = storageInfo.moveBlockToHead (storedBlock, curIindex, headIndex); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








在 上 面 这 个 for 循 环 中 ， 会 进行 新 块 的 扫描 ，processReportedBlock 方 法 中 新 块 的 添加 过 程 如 图 4-5 所 示 。 





























经 过 重重 的 逻辑 判断 ， 最 后 会 执行 添加 块 的 逻辑 。 如 果 图 4-5 中 的 某 个 判断 满足 条 件 ， 将 会 提前 返回 ， 使 之 无 法 成 为 新 的 块 。 比 如 下 面 这 个 判断 处 理 : 























if (shouldPostponeBlocksFromFuture && 
namesystem.isGenStampInFuture (block)) { 
queueReportedBlock (storageInfo, block, reportedState, 
QUEUE REASON FUTURE GENSTAMP); 
return null; 





feelatliielsiiere 


IsSReportedBlock? 


IsinvalidateBlock? 


IsCorruptBlock? 


IsUCBIock? 





插入 





图 4-5 新 块 的 添加 流程 


经 过 这 个 方法 处 理 之 后 ，toAdd 列 表 中 就 会 多 许多 的 新 块 ， 然 后 返回 reportDiff 所 在 的 processReport 方 法 。 








Private Collection<Block> processReport ( 

final DatanodeStorageInfo storageInfo, 

final BlockListAsLongs report) throws IOException { 
// 根据 旧 的 与 新 的 块 报告 之 间 的 不 同 ， 修 改 plock map 中 维护 的 数据 关系 
Collection<BlockInfoContiguous> toAdd = new LinkedList<BlockIinfoContiguous>(); 
Collection<Block> toRemove = new TreeSet<Block>(); 
Collection<Block> toInvalidate = new LinkedList<Block>(); 
Collection<BlockToMarkCorrupt> toCorrupt = new LinkedList<BlockToMarkCorrupt>(); 
Collection<StatefulBlockInfo> toUC = new LinkedList<StatefulBlockInfo>(); 
reportDiff (storageInfo, report, 

toAdd, toRemove, toInvalidate, toCorrupt, toUC); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


for (BlockInfoContiguous b : toAgd) { 
addSstoredBlock (b, storageInfo, null, numBlocksLogged < maxNumBlocksToLog); 
numBlocksLogged++; 

} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















接着 会 调用 addStoredBlock 方 法 ， 这 个 方法 在 上 节 多 余 副 本 块 的 处 理 内 容 中 已 经 提 到 过 ， 它 会 做 一 个 很 关键 的 动作 : 





制 块 列表 。 





判断 待 复制 块 中 是 否 还 存在 此 块 。 如 果 有 ， 则 进行 移 除 ， 及 时 更 新 目前 的 待 复 





// 更 新 内 存 中 维护 的 块 映射 信息 
private Block addSstoredBlock (final BlockIinfoContiguous block, 
DatanodeStorageInfo storageInfo, 
DatanodeDescriptor delNodeHint, 
boolean logEveryBlock) 
throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 处 理 多 余 副本 数 的 情况 
Short fileReplication = bc.getBlockReplication(); 
if (1!1isNeededqReplication (storedBlock, fileReplication, numCurrentReplica)) { 
neededReplications.remove (storedBlock, numCurrentReplica, 
num.decommissionedReplicas(), fileReplication); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 














toAdd 块 添加 的 逻辑 主要 就 是 上 文 所 讲述 的 ， 中 间 略 过 了 一 些 操作 细节 ， 感 兴趣 的 同学 可 自行 阅读 源码 进行 学 习 。 








4.3.3 toRemove: 待 移 除 的 块 


在 日 常生 活 中 ， 我 们 可 能 会 觉得 ， 移 除 的 意思 差不多 就 是 删除 的 意思 ， 但 是 在 ProcessReport 的 块 处 理 方法 中 ， 两 者 并 不 等 同 。 在 移 除 和 删除 操作 之 间 还 隔 了 一 步 操作 。 在 NameNode 这 边 判断 一 个 块 


是 否 为 待 移 除 块 的 标准 是 它 有 没有 在 这 一 轮 被 上 报 上 来 ， 如 果 没 有 ， 则 表明 DataNode 已 经 把 这 个 块 删 了 。 


toRemove 的 含义 是 ， 收 集 那 些 没有 被 汇报 上 来 的 块 ， 将 这 些 块 放 在 delimiter 标 记 块 的 另 一 人 出。delimiter 的 意思 是 分 隔 符 ， 





符 的 两 人 出， 处 理 过 程 如 图 4-6 所 示 。 











简单 概况 这 个 过 程 如 下 : 


1) 首先 会 将 分 隔 符 块 插入 到 链表 头 部 ， 这 样 所 有 的 块 默认 是 未 汇报 过 的 

















2) 其 次 遍历 块 ， 将 汇报 过 的 块 移 到 链表 头 部 ， 这 样 块 的 位 置 就 从 分 隔 符 的 右 侧 挪 到 了 左 侧 。 


3) 于 是 在 本 轮 没 有 被 汇报 处 理 过 的 块 就 全 都 在 分 隔 符 块 的 右 侧 了 。 


这 个 方法 的 设计 思想 是 让 汇报 处 理 过 的 块 和 未 汇报 处 理 过 的 块 分 别 位 于 分 隔 


blockReported 


ReportedBlock1 ReportedBlock2 1 delimiterBlock 


NotReportedBlock1 














4-6 ToRemove 待 移 除 块 的 处 理 远 辑 图 





代码 如 下 ， 大 家 可 以 进行 过 程 的 对 比 : 





// 新 建 一 个 标记 块 用 来 区 分 块 
BlockInfoContiguous delimiter = new BlockInfoContiguous (new Block(), (short) 1) 7 
AddBlockResult result = storageInfo.addBlock (delimiter); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 扫描 处 理 新 的 块 报告 
for (BlockReportReplica iblk : newReport) { 
ReplicaState iState = iblk.getState(); 
// 处 理 新 汇报 上 来 的 块 
BlockInfoContiguous storedBlock = processReportedBlock (storageInfo, 
iblk, iState, oe toInvalidate, toCorrupt, toUC); 
// 如 果 处 理 结果 不 为 空 ， 则 表明 此 块 已 被 正确 处 理 分 类 
// 将 此 块 移 到 标记 块 的 头 部 ， 否 则 在 后 续 操作 中 将 会 被 加 入 到 toRemove 列 表 中 
if (storedBlock != null && 
(curIndex = storedBlock.findStorageInfo (storageInfo)) >= 0) { 
headIndex = storageInfo.moveBlockToHead (storedBlock, curIindex, headIndex); 
} 
k 


// 收集 那些 没有 被 报告 上 来 的 块 
Iterator<BlockInfoContiguous> it = 
storageInfo.new BlockIterator (delimiter .getNext (0)); 
while(it.hasNext ()) 
toRemove .add (it.next ()); 
storageInfo.removeBlock (delimiter); 











一 般 的 块 会 在 processReportedBlock 方 法 中 被 处 理 掉 ， 而 那些 没有 被 处 理 掉 的 块 最 后 会 被 加 入 到 toRemove 列 表 中 ，toRemove 对 象 于 是 就 被 赋值 了 。 然 后 重新 跳 回 到 processReport 方 法 ， 观 察 


toRemove 是 被 如 何 处 理 的 。 





for (Block b : toRemove) { 
removeStoredBlock (b, node); 


} 





进入 removeStoredBlock 方 法 : 





// 更 新 内 存 中 维护 的 块 映射 信息 ， 与 addStoredBlock 类 似 
public void removeStoredBlock (Block block, DatanodeDescriptor node) { 
blockLog.debug ("BLOCK* removeStoredBlock: {} from {}", block, node); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 从 blocksMap 对 象 中 进行 此 块 的 移 除 
if (!blocksMap.removeNode (block, node)) { 
blockLog.debug ("BLOCK* removeStoredBlock: {} has already been" + 
" removed from node {}", block, node); 
return; 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





这 个 方法 做 的 一 步 很 重要 的 操作 是 将 toRemove 中 的 块 从 blocksMap 映 射 关系 中 移 除 掉 。 到 了 这 里 ， 终 于 知道 [emove 的 具体 含义 了 ，remove 指 的 是 blocksMap 的 移 除 动作 。 从 blocksMap 中 移 除 掉 块 
之 后 ， 会 触发 其 他 的 行为 操作 ， 而 并 不 是 一 个 简 简 单单 的 移 除 动作 。 























4.3.4 tolnvalidate: 无 效 的 块 











在 HDFS 中 ， 无 效 的 块 在 某 种 程度 上 来 说 更 接近 于 待 删 除 块 的 意思 。 在 process-ReportedBlock 的 方法 中 ， 无 效 块 最 根本 的 来 源 是 blocksMap 中 不 存在 的 块 。 








// 根 据 块 Ta 找到 对 应 的 块 对 象 
BlockInfoContiguous storedBlock = blocksMap.getStoredBlock (block); 
if(storedBlock == null) { 

// 如 果 blockMap 对 象 中 无 此 块 对 象 ， 则 将 此 块 移入 无 效 块 列表 中 ， 

// 这 个 块 将 从 DataNode 中 删除 

toInvalidate.add (new Block (block)); 

return null; 








所 有 合法 块 的 信息 都 会 被 记录 在 blocksMap 中 ， 所 以 blocksMap 对 象 中 不 存在 块 信息 的 场景 无 外 平 两 种 : 


“ 第 一 种 是 刚刚 toRemove 中 的 块 信息 ， 使 得 blocksMap 移 除了 对 应 的 块 信息 。 








“ 第 二 种 是 新 汇报 上 来 的 块 信息 ，DataNode 自 身 有 这 些 块 信息 ， 而 NameNode 自 身 的 blocksMap 中 没有 ， 也 会 被 认为 是 无 效 块 。 


2 


























第 一 种 场景 好 理解 ， 原 本 就 是 准备 删除 的 块 ， 就 应 该 移 到 无 效 块 中 。 这 里 要 特别 注意 第 二 种 场景 ， 这 个 场景 笔者 在 工作 中 经 历 过 一 次 ， 这 个 场景 挺 奇怪 的 ， 什 么 情况 下 DataNode 有 块 信息 ， 而 
NameNode 中 又 没有 了 呢 ? 答案 是 NameNode 用 早 些 时 间 的 镜像 文件 做 启动 操作 。 因 为 时 间 早 ， 镜 像 文 件 当然 不 会 有 后 面 的 元 数据 信息 ， 所 以 这 个 时 候 如 果 启 动 了 DataNode， 简 直 就 是 灾难 。 你 会 看 到 大 
量 的 块 被 移 到 无 效 块 列 表 中 ， 那 什么 时 候 会 无 意 中 用 了 早期 的 镜像 文件 启动 NameNode 呢 ? 比如 下 面 这 个 条 件 : 




























































































1) NameNode 是 HA 模式 的 。 


2) 某 台 namenode1 进 程 一 个 月 前 挂 了 ， 此 时 另外 一 台 namenode2 切 换 到 了 active 状 态 继续 提供 服务 ， 而 集群 维护 者 并 不 知道 。 


























3) 一 个 月 后 namenode2 需 要 更 改 配置 或 因为 别 的 原因 需要 重启 集群 ， 且 集群 维护 者 并 不 知道 namenode1 已 经 挂 了 一 个 多 月 了 ， 意 外 地 先 启 动 了 namenode1， 而 namenode1 上 的 镜像 文件 已 经 落后 
一 个 多 月 了 。 



































4) 此 时 再 次 重启 所 有 的 DataNode， 就 会 发 生 上 述 大量 块 删除 的 场景 。 











所 以 这 里 给 集群 的 运 维 人 员 一 个 建议 ， 对 于 关键 进程 需要 进行 报警 监控 ， 其 次 每 次 启动 集群 时 要 特别 留意 是 否 出 现 异 常 现象 ， 如 大 量 的 无 效 块 、 日 志 中 大 量 的 删除 操作 记录 等 。 在 任何 情况 下 ， 数 据 的 
安全 性 永远 是 最 重要 的 。 还 好 上 面 这 种 情况 的 bug 在 较 新 的 版 本 中 已 经 被 解决 了 ， 老 的 镜像 文件 如 果 落 后 太 多 将 会 启动 失败 。 图 4-7 是 tolnvalidate 无 效 块 的 处 理 流程 图 。 














网 





























RemoveBlock ve[e| ierei4 


ilerweswElel 


Tolnvalidate 


Return 














图 4-7 TolInvalidate 无 效 块 处 理 逻 辑 





回 到 原来 的 话题 ， 加 入 到 tolnvalidate 块 后 ，tolnvalidate 中 的 块 会 被 加 入 到 invalidate-Blocks 中 : 





for (Block b : toInvalidate) { 
addToInvalidates (b, node); 
} 


// 将 块 加 入 到 无 效 块 列表 中 
void addToInvalidates (final Block block, final DatanodeInfo datanode) { 
if (!namesystem.isPopulatingReplQueues()) { 
return; 
invalidateBlocks.add (block, datanode, true); 


} 





之 后 就 会 触发 删除 操作 了 。 这 部 分 的 操作 将 会 在 BlockManager 内 部 的 Replication-Monitor 监 控 线 程 中 被 调用 : 





private class ReplicationMonitor implements Runnable { 


QOverride 
public void run() { 
while (namesystem.isRunning()) { 


ee 
// 只 有 当 NameNode 退 出 安全 模式 后 ， 才 能 进行 接 下 来 的 操作 
if (namesystem.isPopulatingReplQueues()) { 
computeDatanodeWork (); 
processPendingReplications () 7 
rescanPostponedMisreplicatedBlocks () 7 
} 
Thread. sleep (replicationRecheckInterval); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 computerDatanodeWork 方 法 中 会 进行 这 些 操作 ， 该 方法 的 注释 做 了 很 好 的 解释 : 





* 计算 块 剩余 的 待 复制 的 副本 和 块 需要 被 删除 的 信息 ， 这 些 信息 将 会 在 下 一 次 
* 的 心跳 中 通知 到 对 应 的 pataNode。 
in 返回 因为 副本 复制 或 删除 而 调度 的 块 的 个 数 


int computeDatanodeWork() { 





这 些 无 效 块 各 自 加 入 到 对 应 的 DataNode 描 述 符 信息 中 ， 并 会 在 接 下 来 的 操作 中 通过 心跳 通知 节点 执行 删除 操作 : 





int blockCnt = 0; 
for (DatanodeInfo dnInfo : nodes) { 
int blocks = invalidateWorkForOneNode (dnInfo); 
if (blocks > 0) { 
blockCnt += blocks; 
if (--nodesToProcess 一 0) { 
break; 
} 
} 
































NameNode 50070 端 口 页 面 中 的 PendingDeletionBlock 计 数 其 实 就 是 invalidateBlocks 的 大 小 ， 如 图 4-8 所 示 。 


Decommissioning Nodes 


Total Datanode Volume Failures 


Number of Under-Replicated Blocks 


| Number of Blocks Pending Deletion 21 


Block Deletion Start Time 2016 年 1 月 13 日 GMT+8 下 午 5:19:30 





图 4-8 ”NameNode 页 面 的 PendingDeletionBlock 块 


相关 代码 如 下 : 





QOverride 
Q@Metric 
public long getPendingDeletionBlocks() { 
return blockManager.getPendingDeletionBlocksCount (); 


// 待 删除 块 数 其 实 就 是 无 效 块 的 数量 

public long getPendingDeletionBlocksCount () { 
return invalidateBlocks.numBlocks (); 

} 








tolnvalidate 无 效 块 是 重要 的 ， 知 道 这 些 无 效 块 的 缘由 和 去 向 对 于 处 理 问题 是 非常 有 帮助 的 。 








4.3.5 toCorrupt: 损坏 的 块 








损坏 的 块 一 般 发 生 于 非 系 统 内 部 的 损坏 操作 ， 如 入 工 的 误 删 除 操作 。 损 坏 块 在 NameNode 的 50070 端 口 页 面 的 上 方 区 域 会 显示 出 来 ， 如 





[ 央 











4-9 所 示 。 





Hadoop Oveview Datanodes Datanode Volume Failures Snapshot StartupProgress ”Utilities 


There are 1 missing blocks. The following files may be corrupted: 


gt 


Please check the logs or run fsck in order to identify the missing blocks, See the Hadoop FAQ for common causes and potential solutions. 











4-9 ”NameNode 页 面 的 损坏 块 








在 processReportedBlock 的 处 理 逻 辑 中 ， 对 损坏 块 的 判断 逻辑 主要 在 checkReplicaCorrupt 方 法 中 : 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
BlockToMarkCorrupt C = checkReplicaCorrupt ( 
block, reportedState, storedBlock, ucState, dn); 
if (c != null) { 
if (shouldPostponeBlocksFromFuture) { 
// 如 果 当 前 块 的 版 本 号 值 已 经 超出 了 其 应 有 的 范围 
// 先 加 入 到 报告 队列 ， 等 后 面 的 时 间 再 处 理 
queueReportedBlock (storageInfo， storedBlock, reportedstate, 
QUEUE REASON CORRUPT STATE); 
} else { 
// 将 块 加 入 到 损坏 块 列表 中 
toCorrupt.add (c); 
} 
return storedBlock; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








进入 checkReplicaCorrupt 方 法 ， 你 会 看 到 判断 一 个 块 是 否 为 损坏 状态 的 两 大 主要 因素 : 














private BlockToMarkCorrupt checkReplicaCorrupt( 
Block reported, ReplicaState reportedState, 
BlockInfoContiguous storedBlock, BlockUCState ucSstate, 
DatanodeDescriptor dn) { 
Switch (reportedState) { 
Case FINALIZED: 
Switch (ucState) { 
Case COMPLETE: 
Case COMMITTED: 
// 如 果 块 的 版 本 号 值 不 同 ， 意 味 着 块 的 版 本 信息 发 生变 化 
if (storedBlock.getGenerationstamp() != reported.getGenerationStamp () ) { 
final long reporteqdGS = reported.getGenerationStamp () 7 
return new BlockToMarkCorrupt (storedBlock, reportedes, 
"block is " + ucState + " and reported genstamp " + FreporteqdGS 
+ " does not match genstamp in block map " 
+ storedBlock.getGenerationStamp(), Reason.GENSTAMP MISMATCH); 
} else if (storedBlock.getNumBytes() != reported.getNumBytes()) { 
// 块 大 小 发 生变 化 
return new BlockToMarkCorrupt (storedBlock, 
"block is ”+ ucState + " and reported length "+ 
reported.getNumBytes() + " does not match " + 
"length in block map " + storedBlock.getNumBytes(), 
Reason.SIZE MISMATCH); 
} else { 





return null; // not corrupt 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











一 个 是 长 度 大 小 不 匹配 ， 另 一 个 是 版 本 信息 不 匹配 ， 这 如 何 理解 呢 ? 在 HDFS 中 ， 块 在 创建 完毕 之 后 ， 会 产生 一 个 叫 generationStamp 的 信息 ， 以 后 每 次 块 的 内 容 改 动 ， 这 个 值 都 会 向 前 追加 ， 表 示 块 
版 本 的 变更 。 判 断 完 是 否 为 损坏 的 块 之 后 ， 在 processReport 的 markBlockAsCorrput 方 法 中 ， 会 将 块 加 入 到 corruptReplicas 对 象 里 ， 代 码 如 下 : 











Private void markBlockAsCorrupt (BlockToMarkCorrupt b, 
DatanodeStorageInfo storageInfo, 
DatanodeDescriptor node) throws IOException { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 将 此 副本 加 入 到 损坏 块 map 中 
corruptReplicas.addToCorruptReplicasMap (b.corrupted, node, b.reason, 
b.reasonCode); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











corruptReplicas 对 象 中 的 某 些 方法 信息 会 在 fsck 命 令 中 被 用 到 。 仔 细 留 意 过 NameNode 页 面 损坏 块 信息 的 读者 肯定 会 发 现 ， 这 些 损坏 块 的 信息 每 次 打开 时 都 在 ， 并 不 会 消失 。 的 确 是 这 样 的 ， 除 非 你 
执行 了 fsck 的 -delete 或 -move 操 作 ， 将 损坏 的 块 彻底 删除 掉 了 ， 从 而 使 元 信息 也 被 删除 掉 。 在 NameNode 页 面 上 所 表示 的 损坏 块 的 个 数 就 是 corruptReplicas 对 象 的 大 小 。 
































/** Returns number of blocks with corrupt replicas */ 
@Metric({"CorruptBlocks", "Number of blocks with corrupt replicas"}) 
public long getCorruptReplicaBlocks() { 

return blockManager.getCorruptReplicaBlocksCount (); 
} 


void updatestate() { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
corruptReplicaBlocksCount = corruptReplicas.size(); 


4.3.6 toUC: 正在 构建 中 的 块 


UC 的 全 称 是 UnderConstruction， 正 在 构建 的 意思 ， 表 明 此 块 正在 进行 写 动作 。 判 断 是 否 是 正在 构建 中 的 块 的 逻辑 如 下 : 





if (isBlockUnderConstruction (storedBlock, ucState, reportedState)) { 
toUC.add (new StatefulBlockInfo( 
(BlockInfoContiguousUnderConstruction) storedBlock, 
new Block (block), reportedState)); 
return storedBlock; 
} 


// 判断 块 是 否 处 于 正在 构建 状态 的 方法 
Private boolean isBlockUnderConstruction (BlockInfoContiguous storedBlock, 
BlockUCState ucState, ReplicaState reportedState) { 
Switch (reportedState) { 
Case FINALIZED: 
switch(ucstate) { 
case UNDER CONSTRUCTION: 
case UNDER RFECOVERY: 
return true; 
default: 
return false; 

} 
Case RBW: 
Case RWR: 

return (!storedBlock.isComplete()) 
// 下 面 所 属 副本 状态 的 块 不 会 被 汇报 上 来 ， 不 微 处 理 
Case RUR: 
Case TEMPORARY: 
default: 

return false; 
} 





块 的 状态 根据 传 入 的 副本 状态 进行 判断 。 所 有 UC 的 块 添加 完毕 之 后 ， 进 入 addStore-BlockUnderConstruction: 





// 处 理 正在 构建 中 的 块 
for (StatefulBlockInfo b : toUC) { 
addSstoredBlockUnderConstruction (b, storageInfo); 


} 
void addSstoredBlockUnderConstruction (StatefulBlockInfo ucBlock, 
DatanodeStorageInfo storageInfo) throws IOException { 
BlockInfoContiguousUnderConstruction block = ucBlock.storedBlock; 
block.addReplicaIlfNotPresent ( 
storageInfo, ucBlock.reportedBlock, ucBlock.reportedstate); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 addReplicalfNotPresent 方 法 内 ， 这 些 正在 构建 中 的 块 信息 会 加 入 到 replicas 变 量 列表 中 : 





void addReplicaIfNotPresent (DatanodeStorageInfo storage, 
Block block, 
ReplicaState rstate) { 
Iterator<ReplicaUnderConstruction> it = replicas.iterator () 7 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
replicas.add (new ReplicaUnderConstruction (block, storage, rState)) 于 
} 





replicas 的 定义 如 下 : 





// 正在 构建 中 的 块 


private List<ReplicaUnderConstruction> replicas; 





toUC 的 相关 块 处 理 逻 辑 相对 比较 简单 ， 





EF 要 过 程 就 是 上 面 所 讲述 的 。 








以 上 就 是 本 节 所 讲述 的 上 报 块 处 理 的 五 大 分 支 过 程 ， 每 个 分 支 处 理 都 尽量 地 把 与 其 相关 的 操作 也 纳入 了 进来 。 笔 者 在 解读 此 方面 的 代码 时 ， 略 过 了 一 些 细节 。 如 果 读者 想 要 了 解 更 加 详细 的 过 程 ， 请 阅 
so 





4.4 小 结 








本 章 各 个 小 节 总 体 不 会 太 难 ， 对 于 HDFS 的 fsck 命 令 ， 我 们 只 要 了 解 如 何 使 用 即 可 。 本 章 的 重点 和 难点 主要 在 块 的 汇报 处 理 过 程 ， 理 解 此 过 程 将 会 对 我 们 排除 问题 非常 有 帮助 














第 5 章 ”HDFS 的 流量 处 理 


本 章 将 介绍 HDFS 中 比较 特殊 的 处 理 过 程 : 流量 处 理 。Hadoop 集 群 随 着 规模 的 扩 增 ， 有 的 时 候 每 日 的 吞吐 量 会 很 大 ， 此 时 了 解 它 内 部 的 流量 处 理 细节 非常 有 帮助 。 本 章 主要 从 HDFS 的 内 部 限 流 、 
HDFS 的 Balancer 数 据 平衡 以 及 DiskBalancer 磁 盘 间 数据 平衡 三 方面 的 内 容 来 进行 学 习 。 前 两 部 分 内 容 是 应 用 场景 中 经 常 磁 到 的 ， 而 DiskBalancer 则 是 拓展 的 内 容 。 

















5.1 ”HDFS 的 内 部 限 流 














HDFS 内 部 限 流 的 意思 是 指 在 HDFS 中 对 数据 流量 进行 限制 。 在 HDFS 内 部 ， 每 天 的 数据 吞吐 量 是 巨大 的 ， 一 个 大 任务 往往 会 读 写 超 过 GB 级 别 的 数据 量 。 除 了 运行 任务 之 外 ， 在 HDFS 内 部 还 有 
























































他 一 些 





场合 会 发 生 数 据 的 传输 ， 如 何 对 这 些 场合 进行 流量 的 限制 就 显得 格外 重要 了 。 一 旦 有 大 规模 数据 流量 持续 地 在 传输 ， 就 有 可 能 影响 到 服务 的 正常 运行 。 在 本 节 中 ， 我 们 将 介绍 HDFS 内 部 的 多 个 限 流 场景 、 数 





据 流量 的 限 流 原理 以 及 对 现 有 限 流 方式 的 一 些 改进 想法 。 


5.1.1 ”数据 的 限 流 

















数据 的 限 流 更 让 人 理解 的 称呼 应 该 是 “数据 流 的 限 流 ”。 数 据 流 指 的 是 传输 中 的 源源 不 断 的 数据 。 这 些 数据 传输 会 耗 尽 大 量 的 网 络 带宽 。 一 台 机 器 的 网 络 带宽 必定 是 有 限 的 ， 如 果 带 宽 被 这 台 机 器 上 的 








某 些 任务 占 满 的 话 ， 就 会 影响 正常 任务 的 数据 传输 。 如 果 带 宽 长 时 间 地 被 占 满 ， 还 会 造成 机 器 网 络 IO 报警 ， 所 以 限 流 的 目的 正在 于 此 。 可 能 造成 网 络 带宽 迅速 被 占 满 的 不 一 定 都 是 恶意 的 程序 或 服务 ， 程 序 























中 一 个 朴 忽 的 处 理 或 小 错误 都 可 能 造成 大 规模 数据 的 传输 ， 所 以 与 其 去 劝导 用 户 规范 写 程序 ， 还 不 如 从 系统 层面 进行 管理 限制 ， 把 主动 权 掌握 在 自己 手中 。 
































数据 限 流 的 涉及 面 很 大 ， 因 为 数据 类 型 和 使 用 场景 就 有 很 多 。 所 以 本 节 只 分 析 我 们 想 要 分 析 的 数据 限 流 : Hadoop 内 部 的 限 流 机 制 。 作 为 一 个 大 型 的 分 布 式 存储 系统 ， 数 据 的 读 写 操作 往往 是 非常 频繁 
的 ， 所 以 数据 的 传输 量 一 定 很 大 。 在 数据 量 传输 很 大 的 情况 下 ， 如 何 避 免 出 现 个 别 服务 把 带宽 占 满 的 情况 就 显得 格外 重要 。 有 一 点 是 至 少 需要 保证 的 ， 即 在 Hadoop 中 正在 运行 的 任务 的 读 写 数 据 操作 都 是 

















正常 的 。 为 了 方便 下 文 的 描述 ， 我 们 暂且 称 此 类 型 的 数据 为 “普通 任务 数据 流 ” ， 当 然 还 存在 另外 的 数据 流传 输 ， 而 且 类 型 比 想象 中 更 多 : 
Balancet 数 据 平衡 数据 流传 输 。 
“ Fsimage 镜 像 文件 的 上 传 下 载 数 据 流传 输 。 


“ VolumeScanner 磁 盘 扫 描 时 的 数据 流传 输 。 





看 完 这 3 个 结果 ， 第 一 个 Balancer 的 数据 流传 输 还 是 能 想得到 的 ， 后 面 两 个 如 果 没 有 从 源码 中 进行 分 析 ， 很 容易 会 忽略 掉 。 因 为 以 上 3 种 属 ] 














Hadoop 对 这 3 种 操作 做 了 限 流 操作 。 限 流 相关 的 类 名 叫 作 DataTransferThrottler， 图 5-1 为 HDFS 内 部 的 限 流 结构 。 





VolumeScanner 


DataTransferThrottler klelsSIs /a 


DataXceiverServer 





图 5-1 HDFS 内 部 的 限 流 结构 


5.1.2 ”DataTransferThrottler 限 流 原理 





数据 传输 的 限 流 原 理 在 DataTransferThrottler 中 有 着 非常 巧妙 的 设计 。 先 看 这 个 类 的 源码 注释 : 


Ar 

* 一 个 限制 数据 传输 的 类 。 

* 这 个 类 是 线程 安全 的 ， 它 可 以 被 多 个 线程 共享 ， 带 宽 参 数 bandwidthPerSec 
A 


public class DataTransferThrottler 














F 非 正常 业务 的 数据 流传 输 ， 是 在 系统 自身 内 部 进行 的 ， 所 以 


Felaieu BlockScanner 


BlockBalancer 














通过 传 入 指定 的 带宽 速率 来 作为 一 个 最 大 的 限制 值 ， 在 限制 类 的 作用 下 ， 带 宽 的 平均 速度 将 会 控制 在 这 个 速率 之 下 。 在 这 个 类 中 ， 定 义 了 下 面 几 个 变量 : 








// 单位 周期 时 间 大 小 


private final long period; 

// 最 大 可 累积 的 周期 时 间 

private final long periodExtension; 
// 每 个 周期 内 可 允许 传输 的 总 字 节 大 小 
private long bytesPerPeriod; 

// 当前 周期 的 起 始 时 间 

private long curPeriodstart; 

// 当前 周期 内 剩余 可 传输 字 节 大 小 
private long curReserve; 

private long bytesAlreadyUsed; 





在 DataTransferThrottler 类 中 的 主要 限 流 思想 是 通过 单位 时 间 段 内 限制 指定 字 节 数 的 方式 来 控制 平均 传输 速度 的 。 如 果 发 现 1O 传 输 速 度 过 快 ， 超 过 规定 时 间 内 的 带宽 限定 字 节 数 ， 则 会 进行 等 待 操 作 ， 
等 待 下 一 个 带宽 传输 周期 的 到 来 。 限 流 原 理 如 图 5-2 所 示 。 
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curPeriodStart 
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bytesPerPeriod 


periodExtension = 3 * period 
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5-2 ”DataTransferThrottler 限 流 原理 














因此 每 个 周期 内 的 可 允许 传输 字 节 数 就 是 很 关键 的 变量 ， 它 是 根据 传 入 的 带宽 上 限 值 进 行 转换 的 。 








// 数据 传输 限 流 器 对 象 构造 方法 
public DataTransferThrottler (long period, long bandwidthPerSec) { 
this.curPeriodStart = monotonicNow(); 
this.period = period; 
2 将 甘 席 按照 周期 做 比例 转化 
this.curReserve = this.bytesPerPeriod = bandwidthPerSec*period/1000; 


this.periodExtension = period*3; 















































因为 传 入 的 带宽 是 以 秒 为 单位 的 ， 而 周期 单位 是 毫秒 ， 所 以 要 除 以 1000。curReserve 这 个 变量 的 意思 可 理解 为 当前 可 使 用 的 字 节 传输 量 。 初 始 传输 值 就 是 一 个 周期 的 可 传输 字 节 数 。 
DataTransferThrottler 的 throttle 方 法 是 带宽 限制 的 核心 方法 。 











public synchronized void throttle (long numOfBytes， Canceler canceler) { 
if ( numOfBytes <= 0 ) { 
return; 


a. 
// 当前 可 传输 的 字 节 数 减 去 当前 发 送 、 接 收 字 节 数 


curReserve 一 一 DumOfBytes; 
// 当前 字 节 使 用 量 进行 相应 增加 
bytesAlreadyUsed += numOfBytes; 


// st 说 明 当 前 周期 内 可 使 用 字 节 数 已 经 用 完 
while (curReserve <= 0) 
// 如 果 宙 车 了 odier 浊 象 ， 则 不 会 进行 限 流 操作 
if (canceler != null && canceler.isCancelled()) { 
return; 


} 
long now = monotonicNow(); 
long curPeriodEnd = curPeriodStart + period; 


// 如 果 当 前 时 间 还 在 本 周期 时 间 内 的 话 ， 则 必须 等 待 此 周期 的 结束 ， 
// 重新 获取 新 的 可 传输 字 节 量 
if ( now < curPeriodEnd ) { 
// 等 待 下 一 轮 周 期 到 来 ，curReserve 才 可 以 被 增加 
try { 
wait( curPeriodEnd - now ); 
} catch (InterruptedException e) { 
// 如 果 发 生 中 断 异 常 ， 跳 出 当前 循环 
Thread.currentThread () .interrupt () 7 
break; 
} 
} else if ( now < (curPeriodStart + periodExtension)) 
// 如 果 当 前 时 间 已 经 经 超过 此 半期 的 时 间 且 不 天 于 最 大 周期 间隔 ， 多 in 可 接受 字 节 数 
// 并 更 新 周期 起 始 时 间 为 前 一 周期 的 末尾 时 间 


CurPeriodStart = curPeriodEnd; 











+= bytesPerPeriod; 

} else 
// 后 朱 当前 时 间 超过 curperiodstart + periodExtension, 则 表示 
// 已 经 长 时 间 没 有 使 用 Throttler， 重 置 时 间 
CurPeriodStart = now; 
CurReserve = bytesPerPeriod - bytesAlreadyUsed; 

} 

} 


// 传输 结束 ， 当 前 字 节 使 用 量 进行 移 除 
bytesAlreadyUsed -= numofBytes; 


























从 这 里 可 以 得 到 一 个 启发 ， 影 响 带 宽 平 均 传输 速率 的 指标 不 仅仅 只 有 传 入 的 带宽 速度 上 限 值 参数 ， 周 期 的 设置 同样 也 很 重要 。 带 宽 周 期 设 小 了 ， 发 生 等 待 的 次 数 会 相对 变 多 ， 最 后 的 带宽 平均 速度 就 会 
变 低 。 这 个 问题 在 下 文中 还 会 继续 提 到 。 





5.1.3 ”数据 流 限 流 在 Hadoop 中 的 使 用 
了 解 完 DataTransferThrottler 中 的 限 流 原 理 之 后 ， 我 们 有 必要 了 解 Hadoop 在 哪些 地 方 对 数据 做 了 限 流动 作 。 


1.Balancer 





数据 Balancer 平 衡 的 操作 ， 其 中 Throttler 限 流 器 对 象 是 在 DataXceiverServer 类 中 创建 的 。 





// 初始 化 Balancer 限 流 器 
this.balanceThrottler = new BlockBalanceThrottler( 
conf .getLong (DFSConfigKeys.DFS DATANODE BALANCE BANDWIDTHPERSEC KEY, 
DFSConfigKeys.DFS DATANODE BALANCE BANDWIDTHPERSEC DEFAULT), 
conf.getInt (DFSConfigKeys .DFS_ DATANODE BALANCE MAX NUM CONCURRENT MOVES KEY, 
DFSConfigKeys.DFS_ DATANODE BALANCE MAX NUM CONCURRENT MOVES DEFAULT)); 





下 面 这 个 Balancer 带 宽大 小 配置 属性 就 是 设置 给 Throttler 对 象 的 。 





public static final String DFS DATANODE BALANCE BANDWIDTHPERSEC KEY = "dfs.datanode.balance.bandwidthPerSec"; 
public static final long DFS_DATANODE BALANCE BANDWIDTHPERSEC DEFAULT = 1024*1024; 





默认 带宽 大 小 1MB。 这 个 Throttler 对 象 在 DataXceiver 的 replaceBlock 和 copyBlock 方 法 中 被 调用 。 








QOverride 

public void copyBlock (final ExtendedBlock block, 
final Token<BlockTokenIdentifier> blockToken) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


long beginRead = Time .monotonicNow () 
// 在 读 取 块 数据 时 ， 传 入 Balancez 限 流川 对象 进行 限 流 
long read = blockSender.sendBlock (reply, baseStream, 
dataXceiverServer.balanceThrottler); 
long duration = Time.monotonicNow() - beginRead; 
datanode .metrics.incrBytesRead( (int) read); 
datanode .metrics.incrBlocksRead () 7 
datanode .metrics.incrTotalReadTime (duration); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
QOverride 
public void replaceBlock (final ExtendedBlock block, 
final StorageType storageType, 
final Token<BlockTokenIdentifier> blockToken, 
final String delHint, 
final DatanodeInfo proxySource) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 在 接收 块 时 ， 传 入 Balancer 限 流 器 对 象 进行 限 流 
blockReceiver.receiveBlock (null, null, replyOut, null, 
dataxXceiverServer .balanceThrottler, null, true); 


// 通知 NameNode 已 接收 到 块 
Gatanode .notifyNamenodeReceivedBlock ( 
block, delHint, blockReceiver.getStorageUuid()); 


LOG.info("Moved " + block + " from " + peer.getRemoteAddressString () 
+ ", delHint=" + delHint); 
} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 




















最 后 会 调用 BlockSender 的 sendPacket 和 BlockReceiver 的 receivePacket 方 法 ， 分 别 在 BlockSender、BlockReceiver 类 的 下 面 两 个 方法 中 调用 throttle 的 方法 : 





























Private int sendPacket (ByteBuffer pkt, int maxChunks，OutputStream out, 
boolean transferTo, DataTransferThrottler throttler) throws IOException { 
int dataLen = (int) Math.min (endoffset - offset, 
(chunkSize * (long) maxChunks)); 
// 将 一 个 数据 包 拆 分 为 多 个 chuti 电 法 没 。 下 面 是 计算 需要 发 送 的 chunk 数 量 
int numChunks = numberOfChunks (dataLen); 
int checksumDataLen = numChunks * checksumSize; 
int packetLen = dataLen + checksumDataLen + 4; 
boolean lastDataPacket = offset + dataLen == endOffset && dataLen > 0; 


bt: //www.hzcourse. .Com/ resource/ readBook?path= /openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
0 果 限 流 器 对 象 不 为 空 ， 则 表明 需要 进行 限 流 操作 
if (throttler != null) 全 
throttler.throttle (PacketLen) 
return dataLen; 
} 


Private int receivePacket () throws IOException { 
// 读 取 下 一 个 数据 包 


packetReceiver.receiveNextPacket (in); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 限 流 原理 同上 

if (throttler != null) { 
throttler.throttle (len); 

} 


return lastPacketInBlock?-1:1len; 





因此 可 以 从 侧面 了 解 到 DataXceiver 的 copyBlock 和 replaceBlock 方 法 都 是 在 处 理 Balancer 数 据 平衡 相关 程序 时 使 用 的 。 








2.TransferFslImage 





| 








TransferFslmage 指 的 是 镜像 文件 的 上 传 下 载 过 程 。 可 能 是 Hadoop 的 设计 者 考虑 到 经 常 性 的 镜像 文件 的 传输 对 集群 短 时 间 内 的 带宽 也 会 有 所 影响 ， 因 此 也 进行 了 带宽 限制 的 操作 。 上 传 与 下 载 镜像 文 





件 的 过 程 比较 类 似 ， 以 下 载 镜像 文件 为 例子 : 





QOverride 
protected void doPut (final HttpServletRequest request, 
final HttpServletResponse response) throws ServletException, IOException { 
Ex 
ServletContext context = getServletContext (); 
final FSImage nnImage = NameNodeHttpServer.getFsImageFromContext (context); 
final Configuration conf = (Configuration) getServletContext () 
.getAttribute (JspHelper .CURRENT CONF); 
final PutImageParams parsedParams = new PutImageParams (request, response, 
conf); 
final NameNodeMetrics metrics = NameNode.getNameNodeMetrics () 7 


validateRequest (context, conf, request, response, nnImage, 
parsedParams .getStorageInfoString () ) 7 


UserGroupInformation.getCurrentUser () .doAs( 
new PrivilegedExceptionAction<Void>() { 


QOverride 
public Void run () throws Exception { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


InputStream stream = request.getIinputStream(); 
try { 
tone start = monotonicNow () 7 
// 此 处 传 入 限 流 器 对 象 
MD5Hash downloadImageDigest = TransferFsImage 
.handleUploadImageRequest (request, txiqd, 
nnImage.getStorage (), stream, 
ParsedParams .getFileSize(), getThrottler (conf)); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











其 中 getThrottler 方 法 会 从 配置 文件 的 相关 属性 中 得 到 此 限 流 器 实例 对 象 : 





// 得 到 镜像 文件 传输 限 流 器 对 象 
public final static DataTransferThrottler getThrottler (Configuration conf) { 
long transferBandwidth = 
Conf .getLong (DFSConfigKeys.DFS IMAGE TRANSFER RATE KEY, 
DFSConfigKeys.DFS_ IMAGE TRANSFER RATE DEFAULT); 
DataTransferThrottler throttler = null; 
if (transferBandwidth > 0) { 
throttler = new DataTransferThrottler (transferBandwidth); 


return throttler; 





默认 返回 的 throttler 限 流 器 对 象 为 null， 因 为 限制 带宽 默认 为 0: 








public static final String DFS_IMAGE TRANSFER RATE KEY = 
// 此 默认 值 表明 默认 不 限 流 "dfs.image.transfer.bandwidthPerSec"; 
public static final long DFS IMAGE TRANSFER RATE DEFAULT = 0; 














最 终 在 receiveFile 方 法 中 调用 了 throttle 方 法 : 














Private static MD5Hash receiveFile(String url, List<File> localPaths, 
Storage dstStorage, boolean getChecksum, long advertisedSsize, 
MD5Hash advertisedDigest, String fsImageName, InPutStream stream, 
DataTransferThrottler throttler) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


int num = 1; 
byte[] buf = new byte[HdfsConstants.IO_FILE BUFFER SIZE]; 
while (num > 0) { 加 
num = stream.read (buf) 7 
if (num > 0) { 
received += num; 
for (FileOutputStream fos : outputStreams) { 
fos .write (buf, 0, num); 


} 
// 如 果 限 流 器 对 象 不 为 空 ， 则 表明 此 处 需要 限 流 
if (throttler != null) { 
throttler.throttle (num); 
} 
} 





此 处 限 流 器 是 默认 不 开启 的 。 


3.VolumeScanner 


VolumeScanner 的 意思 是 磁盘 扫描 ， 磁 盘 扫 描 的 目的 是 为 了 发 现 坏 的 块 。 坏 的 块 一 般 发 生 在 读 操作 异常 的 情况 下 ， 所 以 这 个 阶段 读 的 块 会 被 列 为 可 疑 块 。 
影响 ， 特 意 对 磁盘 扫描 的 带宽 做 了 预先 限制 ， 防 止 这 样 一 个 附属 操作 服务 影响 到 正常 业务 。 限 流 操作 在 VolumeScanner 的 scanBlock 方 法 中 被 调用 : 











Hadoop 设 计 者 为 了 确保 本 节点 的 正常 1O 不 受 





// 扫描 块 操作 
private long scanBlock (ExtendedBlock cblock, long bytesPerSec) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
BlockSender blockSender = null; 
try { 
blockSender = new BlockSender (block, 0, -1, 
false, true, true, datanode, null, 
Cachingstrategy.newDropBehind()); 
// 为 限 流 器 对 象 设置 带宽 速率 
throttler.setBandwidth (bytesPerSec); 
// 传 入 限 流 器 对 象 进行 限 流 
long bytesRead = blockSender.sendBlock (nullStream, null, throttler); 
resultHandler.handle (block, null); 
return bytesRead; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





bytesPerSec 带 宽 速 率 值 在 下 面 这 个 方法 中 被 赋值 : 





QSuppressWarnings ("unchecked") 
Conf (Configuration conf) { 
this.targetBytesPerSec = Math.max (0L, conf.getLong( 

DFS_ BLOCK SCANNER VOLUME BYTES PER SECOND, 

DFS_BLOCK_SCANNER VOLUME BYTES PER SECOND DEFAULT)); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
public static final String DFS BLOCK SCANNER VOLUME BYTES PER SECOND = "dfs.block.scanner.volume.bytes.per.second"; 

public static final long DFS_BLOCK SCANNER VOLUME BYTES PER SECOND DEFAULT = 1048576L; 











上 面 代码 的 限 流 大 小 默认 是 1MB， 限 流 部 分 的 操作 就 是 以 上 3 个 部 分 。 


网 
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5-3 为 HDFS 内 部 限 流 执 行 














5.1.4 Hadoop 限 流 优化 点 





学 习 完 整个 限 流 部 分 的 代码 之 后 ， 可 以 看 到 很 多 设计 的 巧妙 之 处 ， 但 是 同样 存在 美中不足 的 地 方 ， 笔 者 总 结 出 了 其 中 两 点 : 
































1) DataTransferThrottler 的 周期 时 间 存 在 硬 编码 的 现象 ， 周 期 长 短 的 设置 对 于 带宽 的 影响 也 不 容 忽视 ， 原 因 在 上 文 已 经 提 到 过 。 目 前 的 设置 是 500 毫 秒 。 


DataTransferThrottle.throttle(numOfBytes) 






















TransferFsimage DataXceiverServer.BlockBalanceThrottler VolumeScanner.scanBlock 


downloadimage uploadimage DataXceiver.replaceBlock DataXceiver.copyBlock 


BlockReceive.receivePacket BlockSendersendPacket 


图 5-3 HDFS 内 部 限 流 详细 执行 图 





Public DataTransferThrottler (long bandwidthPerSec) { 
// 默认 限 流 周 期 5300 毫秒 
this(500, bandwidthPerSec); 

和 














优化 建议 是 将 其 配置 化 处 理 ， 对 于 这 点 笔者 在 学 习 的 过 程 中 已 建立 相关 Issue， 并 提交 给 了 开源 社区 ， 编 号 为 HDFS-9756。Patch 代 码 链接 如 下 : 





https://github.com/linyiqun/open-source-patch/tree/master/hdfs/HDFS-9756 




















2) 上 述 带 宽 限 制 的 场景 都 有 一 个 共同 点 ， 即 都 还 只 是 在 非 任务 层面 做 限制 ， 并 没有 在 正常 的 读 写 块 操作 上 做 限制 。 这 样 的 话 ， 任 务 的 数据 传输 将 会 耗 尽 已 有 带宽 。 笔 者 认为 可 以 把 这 方面 的 限制 也 加 
上 ， 做 成 可 配置 的 ， 默 认 不 开启 正常 的 读 写 带宽 限制 ， 原 理 与 Balancer 的 coplyBlcok 和 replaceBlock 操 作 类 似 。 这 样 的 话 ，readBlock 和 writeBlock 方 法 会 变 得 更 灵活 ， 目 前 readBlock、writeBlock 传 入 的 
throttler 限 流 器 对 象 为 null。 








read = blockSender.sendBlock (out, baseStream, nul1) 7 








这 样 做 的 好 处 是 可 以 根据 机 器 带宽 资源 不 同 ， 进 行 总 带宽 速率 的 限制 。 有 兴趣 的 同学 可 以 自己 试 一 试 。 


HDFS 的 Quota 限 制 


























Throttler 限 流 方案 是 Hadoop 中 限制 资源 使 用 的 一 种 手段 。 其 实在 HDFS 中 ， 还 有 类 似 的 其 他 限制 资源 滥用 的 方法 ， 比 如 Quota 配 额 机 制 。HDFS 中 的 配额 机 制 指 的 是 对 于 每 个 目录 ， 我 们 可 以 设置 该 目 
录 下 的 存储 空间 使 用 (space count) 和 命名 空间 使 用 (namespace count) 计数 ， 命 名 空间 在 此 可 理解 为 子 文件 数 。 通 过 配额 机 制 我 们 可 以 很 好 地 防止 在 目录 下 创建 过 多 的 文件 或 写 入 过 量 的 数据 。 否 
则 ， 就 会 抛 出 异常 。 相 关 代码 的 定义 如 下 : 









































// 文件 /目录 的 Quota 计 数 

public class QuotaCounts { 
// 命名 空间 Quota 限 制 与 磁盘 存储 空间 Quota 限 制 
private EnumCounters<Quota> nsSsCounts; 
// 存储 类 型 空间 的 限制 


private EnumCounters<StorageType> tsCounts; 





这 里 只 做 概括 性 叙述 ， 如 果 有 人 想 深入 了 解 细节 ， 可 自行 阅读 相关 源码 。 


5.2 ”数据 平衡 














对 于 集群 运 维 者 来 说， 维护 集群 各 个 节点 间 数 据 的 平衡 是 一 项 基本 的 运 维 工作 。 如 果 集群 内 各 个 节点 数据 使 用 占 比 参差 不 齐 ， 会 导致 集群 资料 利用 不 充分 。 对 于 数据 相对 多 一 些 的 节点 ， 它 上 面 读 写 的 
数据 量 以 及 运行 任务 数 也 会 偏 多 ， 这 会 间接 造成 不 同 节点 间 负 载 不 均衡 的 问题 ， 从 而 影响 集群 整体 的 运行 效率 。 在 HDFS 中 有 一 个 专门 的 工具 可 以 用 来 解决 这 个 问题 ， 它 的 名 字 叫 做 Balancer。Balancer 工 
具 的 作用 是 将 数据 块 从 高 数据 使 用 量 节点 移动 到 低 数 据 使 用 量 节点 ， 从 而 达到 数据 平衡 的 效果 。 本 节 将 对 此 工具 进行 分 析 和 讲解 ， 主 要 内 容 包 括 Balancer 工 具 运行 的 原理 和 Balancer 程 序 的 改进 优化 。 其 中 
Balancer 程 序 的 改进 优化 是 重点 内 容 ， 因 为 目前 Hadoop 版 本 中 Balancer 工 具 的 运行 效率 并 不 是 特别 高 ， 尤 其 在 数据 规模 比较 大 的 情况 下 ， 这 个 现象 更 加 明显 。 



































































































































5.2.1 _ Balancer 和 Dispatcher 


Balancer 和 Dispatcher 是 与 HDFS Balancer 操 作 最 紧密 关联 的 类 ，Balancer 类 负责 找 出 <source，target> 这 样 的 起 始 、 目 标 节点 对 ， 然 后 存 入 到 Dispatcher 类 中 ， 然 后 通过 Dispatcher 对 象 进 行 分 
发 。 不 过 在 分 发 之 前 ， 会 进行 块 的 验证 ， 判 断 此 块 是 否 能 被 移动 ， 这 里 会 涉及 一 些 条 件 的 判断 ， 具 体 判断 条 件 在 后 面 的 内 容 中 会 进行 介绍 。 











在 Balancer 的 最 后 阶段 ， 会 将 源 节点 和 目标 节点 加 入 到 Dispatcher 对 象 中 ， 详 见 下 面 的 代码 : 





大大 


* 根据 源 节点 和 目标 节点 ， 构 造 任务 对 


private void matchSourceWithTargetToMove (Source source, StorageGroup target) { 
long size = Math.min(source.availableSizeToMove(), target.availableSizeToMove()); 
final Task task = new Task (target, size); 
source.addTask (task); 
target.incScheduledSize (task.getSize()); 
// 加 入 分 发 器 中 
dispatcher.add (source, target); 
LOG.info("Decided to move "+StringUtils.byteDesc(size)+" bytes from " 
+ source.getDisplayName() + " to " + target.getDisplayName () ) 7 





Dispatcher 类 中 的 代码 进行 块 的 分 发 操作 : 





Private <G extends StorageGroup, C extends StorageGroup> 
void chooseStorageGroups (Collection<G> groups, Collection<C> candidates, 
Matcher matcher) { 
for (final Iterator<G> i = groups.iterator(); i.hasNext();) { 
final G g = i.next(); 
for(; choose40One (g， candidates, matcher); ); 
if (!g.hasSpaceForScheduling()) { 
// 如 果 候 选 节点 没有 空间 用 于 调度 ， 则 直接 移 除 掉 
工 .remove () ; 
} 
} 











继续 调用 后 面 的 方法 : 











Ee 
* 从 源 节点 列表 和 目标 节点 列表 中 各 自选 择 节点 组 成 一 对 ， 选 择 顺 序 为 同 节点 组 、 
网 人 个 然后 是 所 有 节点 
x 

private long chooseStorageGroups () { 

if (dispatcher.getCluster() .isNodeGroupAware()) { 
// 首先 匹配 的 条 件 是 同 节点 组 
ChooseStorageGroups (Matcher .SAME NODE GROUP); 





} 


// 然后 是 同 机 架 

chooseStorageGroups (Matcher .SAME RACK); 
// 最 后 是 匹配 所 有 的 节点 
ChooseStorageGroups (Matcher .ANY_OTHER); 





return dispatcher.bytesToMove(); 





然后 再 通过 调用 Dispatcher 的 层 层 方法 ， 最 后 判断 候选 块 是 否 合适 ， 处 理 代码 如 下 : 





/** 
* 决定 一 个 块 是 不 是 一 个 合适 的 候选 块 的 判断 条 件 : 
* 工 . 待 移动 的 块 不 是 正在 被 移动 的 块 
* 2 .在 目标 节点 上 没有 此 移动 块 的 副本 
* 3. 移 动 之 后 ， 不 同 机 架 上 的 块 的 数量 应 该 是 不 变 的 
Af 

Private boolean isGoodBlockCandidate (Source source, StorageGroup target, 

DBlock block) { 
if (source.storageType != target.storageType) { 
return false; 


} 


// 如 果 所 要 移动 的 块 是 存在 于 正在 被 移动 的 块 列表 中 ， 则 返回 false 
if (movedBlocks.contains (block.getBlock())) { 
return false; 


} 
// 如 果 移 动 的 块 已 经 存在 于 目标 节点 上 ， 则 返回 false， 将 不 会 予以 移动 
if (block.isLocatedon (target)) { 

return false; 


} 
// 如 果 开启 了 机 架 感知 的 配置 ， 则 目标 节点 不 应 该 有 相同 的 块 


if (cluster.isNodeGroupAware () 
&& isOnSameNodeGroupWithReplicas (target, block, source)) { 
return false; 


} 
// 需要 维持 机 架 上 的 块 数量 不 变 


if (reduceNumOfRacks (source, target, block)) { 
return false; 
} 


return trues 
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5-4 为 Dispatcher 的 执行 过 程 。 
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图 5-4 ”Dispatcher 内 部 流程 运行 图 


5.2.2 ”数据 不 平衡 现象 








数据 不 平衡 问题 在 集群 规模 尚且 不 大 的 时 候 可 能 不 太 明显 ， 但 是 如 果 集群 规模 数量 达到 成 百 或 上 王 台 机 器 的 时 候 ， 数 据 不 平衡 的 问题 将 会 越 来 越 突出 。 


有 两 大 因素 可 以 导致 节点 之 间 出 现 数据 不 平衡 的 现象 : 














第 一 类 情况 ， 客 户 端 长 期 写 文件 数据 导致 不 均等 的 现象 。 部 分 机 器 写 的 数据 偏 大 ， 而 部 分 机 器 写 的 数据 则 偏 小 。 长 期 积累 导致 了 数据 的 不 平衡 。 








第 二 类 情况 ， 新 节点 的 上 线 。 集 群 新 节点 部 署 上 线 时 ， 上 面 存储 的 数据 都 是 从 零 开始 的 ， 所 以 此 时 也 同样 需要 从 别 的 机 器 中 同步 大 量 的 数据 。 








在 集群 规模 比较 大 的 情况 下 ， 需 要 平衡 的 数据 总 量 也 是 比较 大 的 ， 往 往 可 以 达到 TB 级 别 。 数 据 不 平衡 的 现象 会 造成 拥有 数据 量 较 少 的 一 批 机 器 有 较 多 远程 读 的 操作 ， 而 HDFS 优 先 的 选择 是 大 部 分 的 数 
据 通过 本 地 读 的 方式 获取 。 





5.2.3 Balancer 性 能 优化 














Balancer 工 具 是 专门 用 来 解决 上 文中 所 提 到 的 数据 不 平衡 问题 的 ， 但 是 当 需 要 平衡 的 数据 达到 了 非常 大 规模 的 时 候 ， 当 前 的 Balancer 处 理 罗 辑 是 否 能 帮助 我 们 更 快速 地 将 数据 平衡 呢 》 是 否 有 其 他 的 手 
段 帮助 我 们 提升 其 性 能 呢 ? 



































针对 第 一 个 问题 ， 当 前 的 Balancer 逻 辑 是 否 能 帮助 我 们 更 快速 地 将 数据 平衡 ， 是 否 存在 平衡 效率 不 高 的 场景 呢 ? 笔者 在 使 用 此 工具 的 时 候 发 现 当 HDFS 中 存在 大 量 小 文件 的 情况 时 ，Balancer 数 据 平衡 
的 效率 会 比较 慢 。 再 进一步 分 析 ， 笔 者 发 现 平衡 几 个 大 的 数据 块 的 效率 要 高 于 平衡 更 多 的 小 数据 块 。 换 句 话说 ， 大 数据 块 在 相同 时 间 段 内 数据 平衡 效率 要 远 高 于 小 数据 块 。 所 以 在 这 点 上 ， 我 们 可 以 在 
Balancer 平 衡 程 序 中 加 入 待 移动 块 最 小 字 节 大 小 的 限制 参数 ， 以 此 过 滤 掉 一 些小 数据 块 。 









































其 次 是 第 二 个 问题 ， 是 否 有 其 他 的 手段 能 帮助 我 们 提升 其 性 能 ? 


第 一 个 想到 的 办 法 是 ， 加 大 数据 平衡 的 带宽 。DataNode 中 默认 的 Balancer 带 宽 为 10MB， 在 很 多 情况 下 ， 这 个 值 偏 小 ， 可 以 通过 如 下 命令 统一 调 大 带宽 值 : 





hdfs dfsadmin -setBandwidth <bandwidth> 





带宽 值 同样 不 能 设 得 过 大 ， 以 免 影 响 数据 的 正常 读 写 。 

















第 二 个 方法 ， 指 定 目标 节点 进行 数据 平衡 。Balancer 程 序 默认 是 对 集群 中 全 部 的 节点 进行 数据 的 平衡 。 但 有 的 时 候 ， 我 们 可 以 完全 移 除 掉 使 用 率 接近 于 集群 空间 使 用 率 的 节点 ， 专 门 对 节点 数据 量 少 于 
平均 值 和 数据 量 大 于 平均 值 的 节点 做 数据 平衡 。 这 种 定向 平衡 的 方式 将 会 提升 Balancer 的 整体 效率 。 在 较 新 的 Balancer 版 本 中 ， 所 提供 -include、-exclude 参 数 实现 了 这 个 功能 。 以 include 参 数 为 例子 : 























1) 新 建 include 目 标 平衡 节点 名 称 列表 文件 ， 填 入 目标 节点 的 IP 或 主机 和 名。 
2) 执行 ./start-balancer.sh-include-f hostfile (节点 名 称 列表 文件 的 绝对 路 径 ) 命令 。 


第 三 个 更 加 有 效 的 办 法 是 改造 现 有 Balancer 程 序 的 代码 。 笔 者 基于 hadoop-2.7.1 版 本 的 Balancer 程 序 做 了 许多 改造 。 在 Balancer 主 类 中 新 增 了 以 下 几 个 参数 : 








static class Parameters { 
static final Parameters DEFAULT = new Parameters(5, 1000, 1000 * 60 * 20, 1, 
BalancingPolicy.Node.INSTANCE, 10.0, 
NameNodeConnector .DEFAULT MAX IDLE ITERATIONS, 
Collections.<String> emptySet(), Collections.<String> emptySet ()); 


final BalancingPolicy policy; 
final double threshold; 
final int maxIdleIteration; 


// 最 小 字 节 限制 
final long blockBytesNum; 
// 每 次 兴 代 最 长 时 间 限 制 


final long maxIterationTime; 


// 没有 可 移动 块 情况 下 的 最 大 友 代 次 数 

final long maxNoPendingMoveIterations; 

// 没有 可 条 动 英 时 的 睡眠 时 间 

final long noPendingMoveSleepTime; 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





这 4 个 参数 分 别 解决 了 以 下 几 方面 的 性 能 问题 : 














1) blockBytesNum 最 小 字 节 限制 。 这 点 是 为 了 解决 在 上 文中 提 到 的 大 量 小 文件 块 造成 的 数据 平衡 效率 偏 低 的 问题 。 在 每 次 筛选 块 的 时 候 ， 额 外 做 一 次 块 大 小 的 筛选 判断 


增 如 下 代码 : 


断 ， 这 需要 在 Dispatcher 类 中 新 





private boolean isGoodBlockCandidate (StorageGroup source, StorageGroup target， 
StorageType targetStorageType, DBlock block) { 
if (source.equals (target)) { 
return false; 
} 
if (target.storageType != targetStorageType) { 
return false; 


¢ 


// 检查 此 块 是 否 已 经 被 迁移 过 ， 如 果 是 ， 则 此 块 不 是 候选 块 
if (movedBlocks.contains (block.getBlock())) { 
return false; 
} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
Wea 新 前 其 类 小 第 选 判断 逻辑 
if (block.getNumBytes() < this.blockBytesNum) { 
LOG.debug ("is bad block, reason: block byte num < " + this.blockBytesNum); 
return false; 


} 


return true; 





2) maxlterationTime 每 次 迭代 最 长 时 间 限制 。 这 里 的 迭代 时 间 指 的 是 每 一 轮 数 据 平衡 所 花 的 总 时 间 。 加 上 这 个 时 间 是 为 了 避免 单 次 迭代 周期 所 花 的 时 间 过 长 。 





private void dispatchBlocks() { 
final long startTime = Time.monotonicNow(); 
this.blocksToReceive = 2 * getScheduledSize(); 
boolean isTimeUp = false; 
int noPendingMoveIteration = 0; 
while (!isTimeUp && getScheduledSsize() > 0 
&& (!srcBlocks.isEmpty() || blocksToReceive > 0)) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 检测 是 否 已 经 达到 最 大 时 间 限 制 


if (Time. | - startTime > Dispatcher.this.maxIterationTime) { 
LOG.info("source: " + this.getDatanodeInfo() + " is time up."); 
isTimeUp = true; 
continue; 


Ek 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} 


LOG.info("source: " + this.getDatanodeInfo() + " exit!"); 
bE: 





3) maxNoPendingMovelterations 没 有 可 移动 块 情况 下 的 最 大 和 迭代 次 数 。Balancer 数 据 平衡 程序 会 在 连续 5 次 没有 找到 可 移动 块 的 情况 下 退出 程序 ， 所 以 我 们 需要 能 够 让 它 持久 地 跑 下 去 ， 可 以 增加 


此 参数 。 当 然 最 好 搭配 上 另外 一 个 参数 noPendingMovesleepTime， 这 样 可 以 保证 有 足够 的 时 间 间 隔 。 


Private void dispatchBlocks() { 
final long startTime = Time.monotonicNow(); 
this.blocksToReceive = 2 * getScheduledSize(); 
boolean isTimeUp = false; 
int noPendingMoveIteration = 0; 
while (!isTimeUp && getScheduledSsize() > 0 


&& (!srcBlocks.isEmpty() || blocksToReceive > 0)) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
} else { 


// 源 端 节点 没有 可 移动 的 块 时 ，noPendingMoveIteration 计 数 加 1 

noPendingMoveIterationt+; 

// 进行 noPendingMoveIteration 人 迭代 次 数 的 判断 ， 防 止 原 逻 辑 中 经 过 连续 5 次 的 

noPendingMove 迭 代 后 退出 的 现象 

if (noPendingMoveIteration >= Dispatcher.this.maxNoPedingMoveIterations) { 
LOG.info("source: " + this.getDatanodeInfo() + " noPendingMoveIteration is finished." ); 
resetScheduledSize(); 

} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





4) noPendingMovesleepTime 没 有 可 移动 块 时 的 睡眠 时 间 。 这 个 参数 指 的 是 Balancer 程 序 在 没有 找到 可 移动 块 前 提 下 的 缓冲 时 间 ， 在 以 下 代码 中 进行 添加 : 





private void dispatchBlocks() { 
final long startTime = Time.monotonicNow(); 
this.blocksToReceive = 2 * getScheduledSize(); 
boolean isTimeUp = false; 
int noPendingMoveIteration = 0; 
while (!isTimeUp && getScheduleqdSize() > 0 
&& (!srcBlocks.isEmpty() || blocksToReceive > 0)) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 当 目 前 处 于 找 不 到 块 的 情况 时 ， 等 待 一 段 时 间 
ed (Dispatcher.this) { 
Dispatcher.this.wait (Dispatcher.this.noPedingMoveSleepTime); // wait for targets/sources to be idle 
} Een (InterruptedException ignored) { 
5 


LOG.info("source: " + this.getDatanodeInfo() + " exit!"); 





以 上 4 个 参数 的 改造 是 笔者 在 工作 中 一 点 点 去 完善 的 。 在 社区 上 同样 有 相应 的 RA 来 提升 Balancer 的 性 能 : HDFS-8825 (Enhancements to Balancer) ， 上 文 做 了 很 多 方面 的 优化 ， 包 括 小 文件 块 的 问 








题 ， 社 区 也 做 了 相应 的 改进 ， 同 样 包含 在 这 个 JIRA 内 部 了 。 


5.3 ”HDFS 节 点 内 数据 平衡 














上 一 节 中 我 们 讲述 了 HDFS 节 点 间 数 据 平衡 的 问题 ， 在 本 节 我 们 把 目光 移 向 节点 内 的 数据 平衡 问题 。 现 有 Balancer 工 具 并 不 能 帮助 我 们 平衡 节点 内 各 个 磁盘 间 的 数据 ， 磁 盘 间 数 据 的 不 同 会 造成 磁盘 IO 
























































压力 的 不 同 。 在 HDFS 中 ， 同 样 有 类 似 的 工具 专门 做 这 样 的 事情 : DiskBalancer。 很 显然 ，DiskBalancer 工 具 操作 的 范围 是 在 一 个 节点 内 。 此 功能 目前 并 未 发 布 ， 但 是 核心 设计 已 经 基本 上 开发 完毕 了 ， 详 
见 JIRA: HDFS-1312 (Re-balance disks within a Datanode) 。 目 前 社区 在 完善 相关 命令 使 用 与 文档 方面 的 工作 。 想 要 提前 使 用 此 功能 ， 可 以 自行 获取 Hadoop 工 程 中 HDFS-1312 的 分 支 代码 。 本 节 我 们 
将 要 提前 来 学 习 与 了 解 DiskBalancer 相 关 的 内 容 。 在 本 节 中 ， 我 们 将 首先 讲述 传统 磁盘 间 平 衡 的 做 法 ， 然 后 再 引入 社区 方案 DiskBalancer， 并 对 此 方案 进行 详细 的 讲述 。 本 节 部 分 内 容 参 考 了 社 
DiskBalancer 的 设计 文档 。 


































































































M4 


5.3.1 ”磁盘 间 数 据 不 平衡 现象 及 问题 


磁盘 间 数 据 不 平衡 的 现象 源 自 于 长 期 写 操作 时 数据 大 小 的 不 均衡 。 因 为 每 次 写 操作 可 以 保证 写 磁盘 的 顺序 性 ， 但 是 无 法 保证 每 次 写 入 的 数据 量 都 是 一 个 规模 大 小 。 比 如 A、B、C、D 四 块 盘 ， 我 们 用 默 
认 的 RoundRobin ( 轮 询 ) 磁盘 选择 策略 去 写 。 最 后 四 块 盘 的 确 是 都 写 过 了 ， 但 是 A、B 可 能 写 的 块 较 小 ， 就 1MB， 而 C、D 可 能 就 是 写 满 的 块 ，128MB。 



































如 果 磁 盘 间 数据 不 平衡 现象 确实 出 现 了 ， 它 会 给 我 们 造成 什么 影响 呢 ; 有 人 可 能 会 想 ， 它 不 就 是 一 个 普通 磁盘 嘛 ， 又 不 是 系统 盘 ， 系 统 盘 使 用 空间 过 高 是 会 影响 系统 性 能 的 ， 但 是 普通 盘 应 该 问题 不 大 
吧 。 这 个 观点 听 上 去 是 没 问题 ， 但 是 只 能 说 它 考虑 的 太 浅 了 。 我 们 从 HDFS 的 读 写 层面 来 对 这 个 现象 做 一 个 分 析 。 这 里 归纳 出 了 以 下 两 点 : 
































第 一 点 ， 磁 盘 间 数 据 不 平衡 间接 引发 了 磁盘 IO 压力 的 不 同 。 我 们 都 知道 HDFS 上 的 数据 访问 频率 是 很 高 的 ， 这 会 涉及 大 量 读 写 磁 盘 的 操作 ， 数 据 多 的 盘 自然 就 会 有 更 高 频率 的 访问 操作 。 如 果 一 块 盘 的 
10 操 作 非 常 密集 的 话 ， 势 必 会 对 它 的 读 写 性 能 造成 影响 。 









































第 二 点 ， 高 使 用 率 磁 盘 导 致 可 选 存储 目录 减少 。HDFS 在 写 块 数据 的 时 候 ， 会 挑选 那些 剩余 可 用 空间 能 满足 待 写 块 大 小 的 磁盘 。 如 果 高 使 用 率 磁 盘 目录 过 多 ， 会 导致 这 样 的 候选 块 变 少 。 所 以 这 会 对 
HDFS 产 生 影 响 。 


























5.3.2 ”传统 的 磁盘 间 数 据 不 平衡 解决 方案 


磁盘 间 数 据 不 平衡 现象 出 现 了 ， 目 前 我 们 有 什么 办 法 解决 呢 ? 下 面 是 两 种 现 有 解决 方案 : 





:方案 一 : 节点 下 线 再 上 线 。 将 节点 内 数据 不 平衡 的 机 器 进行 Decommision 下 线 操 作 ， 下 线 之 后 再 次 上 线 。 上 线 之 后 相当 于 是 一 个 全 新 的 节点 了 ， 数 据 也 将 会 重新 存储 到 各 个 盘 上 。 这 种 做 法 给 人 感觉 会 
比较 粗暴 ， 当 集群 规模 比较 小 的 时 候 代 价 太 高 ， 此 时 下 线 一 个 节点 会 对 集群 服务 造成 不 小 的 影响 。 


: 方案 二 : 人 工 移动 部 分 数据 块 存储 目录 。 此 方案 相 比 方案 一 更 加 灵活 一 些 ， 但 是 数据 目录 的 移动 要 保证 准确 性 ， 否 则 会 造成 移动 完 目录 后 数据 找 不 到 的 现象 。 下 面 举 一 个 实际 的 例子 ， 比 如 我 们 想 将 
磁盘 1 上 的 数据 挪 到 磁盘 2 上 。 现 有 磁盘 1 的 待 移动 存储 目录 如 下 : 





/data/1l/dfs/dn/ current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/ finalized/subdir0/subdir1/ 


我 们 移动 到 目标 盘 上 的 路 径 应 该 维持 这 样 的 路 径 格 式 不 变 ， 只 变化 磁盘 所 在 的 目录 ， 目 标 路 径 如 下 : 








/data/2/dfs/dn/current/BP-1788246909-xx.xx.xx.xx-1412278461680/current/finalized/subdir0/subdir1/ 





如 果 上 述 目录 结构 出 现 变化 ， 就 会 造成 HDFS 找 不 到 此 数据 块 的 情况 。 


5.3.3 ”社区 解决 方案 : DiskBalancer 




















前 面 铺垫 了 这 么 多 的 内 容 ， 是 为 了 引出 本 节 要 重点 讲述 的 主题 : DiskBalancer。Disk-Balancer 从 名 字 上 可 以 看 出 ， 它 是 一 个 类 似 于 Balancer 的 数据 平衡 工具 。 但 是 它 的 作用 范围 是 被 限制 在 了 磁盘 上 。 
首先 这 里 要 说 明 一 点 ，DiskBalancer 目 前 是 未 发 布 的 功能 特性 ， 所 以 我 们 在 现 有 发 布 版 本 中 是 找 不 到 此 工具 的 。 下 面 笔 者 将 会 全 方面 介绍 DiskBalancer， 让 大 家 认识 、 了 解 这 个 强大 的 工具 。 







































































1.DiskBalancer 的 设计 核心 











首先 我 们 先 来 了 解 DiskBalancer 的 设计 核心 ， 这 与 Balancer 有 一 点 点 的 区 别 。Balancer 的 核心 点 在 于 数据 的 平衡 ， 数 据 平 衡 好 就 可 以 了 。 而 DiskBalancer 在 设计 的 时 候 提 出 了 两 点 目标 : 
































第 一 点 ，Data Spread Report (数据 分 布 式 的 汇报 ) 。 这 是 一 个 汇报 的 功能 。 也 就 是 说 ，DiskBalancer 工 具 能 支持 各 个 节点 汇报 磁盘 块 使 用 情况 的 功能 ， 通 过 这 个 功能 集群 管理 者 能 够 了 解 到 目前 集群 
内 使 用 率 最 高 的 一 些 节点 、 磁 盘 。 
































第 二 点 ，Disk Balancing。 第 二 点 才 是 磁盘 数据 的 平衡 。 但 是 在 磁盘 内 数据 平衡 的 时 候 ， 要 考虑 到 各 个 磁盘 存储 类 型 的 不 同 。 之 前 提 到 过 HDFS 的 异 构 存 储 ， 不 同 盘 可 能 配置 的 存储 类 型 会 不 同 ， 目 前 
DiskBalancer 不 支持 跨 存 储 类 型 的 数据 转移 ， 所 以 目前 都 是 要 求 在 同一 个 存储 类 型 下 。 


以 上 两 点 取 自 于 DiskBalancer 的 设计 文档 (DiskBalancer 相 关 设计 文档 可 见 Apache 社 区 JIRA: HDFS-1312) 。 








2.DiskBalancer 的 架构 设计 








此 部 分 讨论 DiskBalancer 的 架构 设计 。 通 过 架构 设计 ， 我 们 能 更 好 地 了 解 它 的 一 个 整体 情况 。 图 5-5 为 DiskBalancer 的 核心 架构 设计 。 














上 面 过 程 经 过 了 3 个 阶段 ， 首 先 从 Discover (发 现 ) 到 Plan (计划 ) ， 再 从 Plan (计划 ) 到 Execute (执行 ) 。 下 面 来 详细 解释 这 3 个 阶段 。 














Discover 


Plan 


Execute 








5-5 ”DiskBalancer 的 架构 设计 图 








Discover 阶 段 









































发 现 阶段 做 的 事情 实际 上 是 通过 计算 各 个 节点 内 的 磁盘 使 用 情况 ， 得 出 需要 数据 平衡 的 磁盘 列表 。 这 里 会 通过 Volume Data Density (磁盘 使 用 密度 ) 的 概念 作为 一 个 评判 的 标准 ， 这 个 标准 值 将 会 以 
节点 总 使 用 率 作为 比较 值 。 举 个 例子 ， 如 果 一 个 节点 总 使 用 率 为 75%， 就 是 0.75， 其 中 A 盘 实际 使 用 率 0.5 (50%) ， 那 么 A 盘 的 volumeDataDensity 密 度 值 就 等 于 0.75-0.5=0.25。 同 理 ， 如 果 超 出 节点 总 使 
率 的 话 ， 则 密度 值 将 会 为 负数 。 于 是 我 们 可 以 用 节点 内 各 个 盘 的 volumeDataDensity 的 绝对 值 来 判断 此 节点 内 磁盘 间 数 据 的 平衡 情况 。 如 果 总 的 绝对 值 的 和 越 大 ， 说 明 磁 盘 间 数据 越 不 平衡 ， 这 有 点 类 似 
于 方差 的 概念 。Discover 阶 段 将 会 用 到 如 下 连接 器 对 象 : 








































































































”DBNameNodeConnector 


“JsonConnector 


* NullConnector 























其 中 第 一 个 对 象 会 调用 到 Balancer 包 下 的 NameNodeConnector 对 象 ， 以 此 来 读 取 集群 中 的 节点 、 磁 盘 等 数据 信息 。 
Plan 阶段 
拿 到 上 一 阶段 的 汇报 结果 之 后 ， 将 会 进行 执行 计划 的 生成 。Plan 并 不 是 一 个 最 小 的 执行 单元 ， 它 的 内 部 由 各 个 step 组 成 。step 中 会 指定 好 源 、 目 标 磁盘 。 这 里 的 磁盘 对 象 是 一 层 经 过 包装 的 对 象 : 








DiskBalancerVolume， 并 不 是 原来 的 FsSVolume 磁 盘 对 象 。 以 下 是 DiskBalancer 中 对 磁盘 、 节 点 等 概念 的 定义 : 
“ DiskBalancerCluster。 通 过 此 对 象 可 以 读 取 到 集群 中 的 节点 信息 ， 这 里 的 节点 信息 以 DiskBalancerDataNode 的 方式 所 呈现 。 
“ DiskBalancerDataNode。 此 对 象 代 表 的 是 一 个 包装 好 后 的 将 会 进行 磁盘 数据 平衡 的 DataNode。 


* DiskBalancerVolume 和 DiskBalancerVolumeSet。DataNode 磁 盘 对 象 以 及 磁盘 对 象 集合 。DiskBalancerVolumeSet 内 的 磁盘 存储 目录 类 型 需要 是 同 种 存储 类 型 。 


Execute 阶 段 





最 后 一 部 分 是 执行 阶段 ， 所 有 的 计划 生成 好 了 之 后 ， 就 到 了 执行 阶段 。 这 些 计划 会 被 提交 到 各 自 的 DataNode 上 ， 然 后 在 DiskBalancer 类 中 执行 。DiskBalancer 类 中 有 专门 的 类 对 象 来 做 磁盘 间 数 据 平 
衡 的 工作 ， 这 个 类 的 名 称 叫做 DiskBalancerMover。 在 磁盘 间 数 据 平衡 的 过 程 中 ， 高 使 用 率 的 磁盘 会 移动 数据 块 到 相对 低 使 用 率 的 磁盘 上 ， 等 到 满足 一 定 阅 值 关系 的 情况 下 时 ，DiskBalancer 将 会 退出 。 在 
DiskBalancer 的 执行 阶段 ， 有 以 下 3 项 可 以 通过 配置 控制 |: 


























“ 带宽 的 限制 。DiskBalancer 中 同样 可 以 支持 带宽 的 限制 ， 默 认 是 10MB， 通 过 配置 项 dfs.disk.balancer.max.disk.throughputInMBperSec 进 行 控 制 。 
“ 失败 次 数 的 限制 。DiskBalancer 中 会 存在 失败 次 数 的 控制 。 在 拷贝 数据 块 的 时 候 ， 出 现 IOException 等 异常 ， 会 进行 失败 次 数 的 累加 计数 ， 如 果 超 出 最 大 容忍 值 ，DiskBalancer 也 会 退出 。 


' 数据 平衡 阔 值 控制 。DiskBalancer 中 可 以 提供 一 个 磁盘 间 数 据 的 平衡 阔 值 ， 以 此 作为 是 否 需要 继续 平衡 数据 的 判断 标准 ， 配 置 项 为 dfs.disk.balancetr.block.tolerance.percent。 


3.DiskBalancer 的 代码 结构 





DiskBalancer 的 相关 代码 最 近 已 经 合 入 hadoop-trunk 中 了 ， 大 家 在 HDFS-1312 和 hadoop-trunk 中 都 可 以 进行 阅读 学 习 。 笔 者 基于 hadoop-trunk 分 支 ， 对 DiskBalancer 进 行 了 代码 结构 的 分 析 。 








目前 基本 上 所 有 的 DiskBalancer 相 关 的 代码 都 在 org.apache.hadoop.hdfs.server.diskbalancer 包 下 ， 在 此 包 下 又 分 出 了 4 个 子 目录 : 
“ command: 此 目录 下 存放 DiskBalancer 相 关 的 使 用 命令 。 

“ connectors; 此 目录 下 存放 了 一 些 用 以 读 取 节点 、 磁 盘 信息 的 连接 器 对 象 类 。 

. datamodel: 此 目录 下 定义 了 DiskBalancer 中 的 数据 实体 类 。 


“ planner: 此 目录 下 包含 了 plan 计 划 相 关 类 ， 用 于 在 plan 阶 段 生成 计划 。 





5-6 所 示 为 DiskBalancer 的 代码 组 成 结构 。 
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以 上 4 个 子 目录 加 上 DiskBalancer 的 主 执行 类 和 tool 包 下 的 DiskBalancer 命 令 入 口 类 ， 就 构成 了 DiskBalancer 的 总 代码 结构 。 





4.DiskBalancer 的 命令 执行 








DiskBalancer 内 部 提供 了 许多 类 型 的 命令 操作 ， 比 如 下 面 的 查询 命令 : 











hdfs diskbalancer -query nodename.mycluster.com 





> 出 org.apache.hadoop.hdfs.server.diskbalancer 
了 册 org.apache.hadoop.hdfs.server.diskbalancercommand 
四 CancelCommand.java 
> 月 CommandJjava 
上 月 ExecuteCommand.java 
> 月 HelpCommand.java 
> 月 package-info.java 
> 月 PlanCommand.java 
> | QueryCommand.java 
> [ND ReportCommand.java 
Vv 山 org.apache.hadoop.hdfs.server.diskbalancerconnectors 
> 月 ClusterConnectorjava 
4 器 ConnectorFactory.java 
> 月 DBNameNodeConnectorjava 
> 月 JsonNodeConnectorjava 
> 四 package-info.java 
Vv 有 岂 org.apache.hadoop.hdfs.server.diskbalancer.datamodel 
> 月 DiskBalancerCluster.java 
> 月 DiskBalancerDataNode.java 
> |N DiskBalancerVolume.java 
> [ND DiskBalancerVolumeSet.java 
> |N package-info.java 
立山 org.apache.hadoop.hdfs.server.diskbalancerplanner 
> 月 GreedyPlannerjava 
月 MoveStep.java 
> 月 NodePlan.java 
> |N package-info.java 
> 月 Plannerjava 
> 四 PlannerFactory.java 
> |N Step.java 








图 5-6 ”DiskBalancet 代 码 结构 图 











我 们 也 可 以 执行 相应 的 plan 命 令 来 生成 plan 计 划 文 件 : 





hdfs diskbalancer -uri hdfs://mycluster.com -plan nodel .mycluster.com 














然后 可 以 用 生成 好 后 的 json 格 式 的 plan 文 件 进行 DiskBalancer 的 执行 : 














hdfs diskbalancer -execute /system/diskbalancer/nodename.plan.json 





如 果 发 现 执行 了 错误 的 plan， 我 们 可 以 通过 cancel 命 令 进行 清除 : 


hdfs diskbalancer -cancel /system/diskbalancer/nodename.plan.json 





或 





hdfs diskbalancer -cancel <planID> -node <nodename> 





在 DiskBalancer 中 会 涉及 比较 多 的 object-json 的 关系 转换 ， 所 以 你 会 看 到 一 些 带 .json 后 绎 的 文件 。 





























总 的 来 阅 ，DiskBalancer 是 一 个 很 实用 的 功能 特性 。 在 Hadoop 中 ， 有 专门 的 分 支 用 于 此 功能 的 开发 ， 分 支 名 HDFS-1312。 感 兴趣 的 同学 可 以 下 载 Hadoop 的 最 新 代码 进行 学 习 。 笔 者 非常 荣幸 地 也 向 
此 功能 提交 了 一 个 小 patch，JIRA 编 号 HDFS-10560。 这 个 功能 很 快 就 要 在 新 版 的 Hadoop 中 发 布 了 ， 相 信 会 对 Hadoop 集 群 管理 人 员 非 常 有 帮助 。 


5 趟 水 结 




















本 章 主要 讲述 了 在 HDFS 中 对 于 数据 流量 的 处 理 。 了 解 HDFS 内 部 的 各 个 限 流 场景 以 及 Balancer 的 限 流 原理 对 于 我 们 来 说 是 比较 重要 的 。 本 章 的 一 个 难点 是 Balancer 的 优化 ， 目 前 HDFS 的 Balancer 数 据 
平衡 效率 并 不 算 太 高 ， 还 需要 我 们 在 日 后 的 实践 和 使 用 中 进一步 地 优化 。 
































第 6 章 ”HDFS 的 部 分 结构 分 析 








本 章 我 们 将 会 学 习 了 解 HDFS 内 部 一 些 特 殊 的 结构 对 象 和 过 程 的 分 析 ， 了 解 这 些 对 象 的 特殊 作用 或 是 其 独特 的 设计 。 本 章 主要 分 为 3 个 部 分 。 第 一 节 ，HDFS 镜 像 文件 的 解析 与 反 解析 过 程 。 第 二 
节 ，HDFS 的 数据 处 理 过程 以 及 数据 处 理 中 心 对 象 DataXceiver。 第 三 节 ，HDFS 邻 近 信息 块 对 象 BlockinfoContiguous， 此 节 内 容 将 会 让 我 们 了 解 到 块 对 象 是 如 何 被 组 织 起 来 的 。 











6.1 ”HDFS 镜 像 文 件 的 解析 与 反 解析 




















HDFS 镜 像 文 件 的 解析 与 反 解析 应 该 拆 分 成 “解析 ”过 程 和 “ 反 解 析 ”′ 过 程 。 其 中 “解析 ”过 程 的 意思 是 指 把 HDFS 的 镜像 文件 解析 成 用 户 可 识别 的 文件 形式 ， 比 如 XML 文 件 格式 。 而 “ 反 解 析 ” 过 程 则 
是 “解析 ”步骤 的 逆 过 程 ， 它 会 将 XML 格式 的 镜像 文件 重新 转化 为 镜像 文件 原 有 的 格式 ， 即 NameNode 能 够 识别 读 取 的 格式 。 镜 像 文 件 包 含 着 集群 中 所 有 文件 元 数据 的 信息 ， 在 很 多 场合 下 ， 我 们 需要 能 
读 取 到 它 的 数据 。 通 过 解析 与 反 解 析 的 过 程 ， 用 户 可 以 更 加 方便 地 使 用 镜像 文件 。 这 里 需要 注意 一 点 ， 反 解析 功能 是 社区 最 近 完 成 的 功能 ， 相 关 咱 RA: HDFS-9835 (OIV:add ReverseXML processor 
which reconstructs an fsimage from an XML file) 。 在 本 节 中 ， 将 主要 讲述 HDFS 镜 像 文件 的 解析 与 反 解析 的 过 程 ， 然 后 介绍 相关 命令 hdfs oiv 和 hdfs oev 的 使 用 。 
















































































6.1.1 HDFS 的 FslImage 镜 像 文件 





在 详细 了 解 镜 像 文件 的 解析 与 反 解析 之 前 ,我 们 需要 对 Fslmage 有 一 个 初步 的 了 解 。 


1.Fslmage 的 存储 位 置 


没有 专门 运 维 过 Hadoop 集 群 的 同学 可 能 只 是 或 多 或 少 听 到 过 这 个 名 词 ， 但 是 真正 见 到 过 ， 打 开 看 过 此 文件 内 容 的 人 应 该 不 多 。 即 便 你 打开 了 ， 你 看 到 的 应 该 是 这 样 的 乱码 : 


HDFSIMG1^V^H,<8c>fE^D^PE^G^XO^G ^ 人 ae(<8c><80><80><80>^DOP^PF^H<95><80>^A^P^U1^H^B 
^P<81> 

<80>^A^Z^@*'^H<94>% <99>1x^ 人 PYyYyYyYYyYYYY^ 人 ?2^XYYYYYYYYY^AIT^ 人 A^ 人 A^ 人 G^ 人 Ge^e^e^e:^Q6^H^B^P<82 
><80>^A^Z^Ddir0* (^HIi% 

<99>1x^ 人 PYyYVyYYYYYY^A^XYYYYYYYYY^AIT^ 人 A^ 人 A^G^e^ 人 Ge^e^e:^e<^H^A^P<83><80>^A^Z^EfEile0"- 
^H^A^P §% 





可 能 会 有 人 疑问 为 什么 是 这 样 的 呢 ? 这 里 笔者 认为 有 两 点 原因 : 





第 一 点 ， 因 为 考虑 到 元 数据 信息 可 能 随 着 数据 的 变 多 而 不 断 变 大 ， 为 了 缩小 文件 的 空间 大 小 ， 需 要 存储 为 二 进 制 文件 。 





第 二 点 ， 进 行 编码 处 理 ， 避 免 直接 明文 保存 的 不 安全 性 。 





第 二 点 原因 是 笔者 的 个 人 看 法 ， 主 要 还 是 第 一 点 。 镜 像 文件 的 位 置信 息 由 以 下 配置 项 所 控制 : 








<property> 

<name>dfs .namenode.name.dir</name> 
<value></value> 

</property> 





2.Fslmage 的 存储 信息 


下 面 列举 几 个 常见 的 可 能 存储 的 信息 : 


. 文件 目录 信息 


“位置 信息 


“ 副本 数 


“ 权限 信息 











以 上 几 点 就 是 传统 意义 上 的 元 信息 组 成 部 分 了 ， 但 是 很 显然 ，HDFS 有 它 自己 的 独特 性 ，Fslimage 保 存 的 类 型 信息 远 远 多 于 此 ， 下 文中 还 将 会 提 到 。 











6.1.2 ”Fslmage 的 解析 

















Fslmage 镜 像 文件 的 解析 指 的 是 将 HDFS 镜 像 文 件 解析 成 使 用 者 能 直接 阅读 的 形式 ， 而 不 是 像 上 文中 出 现 的 乱码 。 这 里 就 不 得 不 提 到 一 个 重要 的 解析 类 : PBImageXmlWriter。 解 析 成 XML 文件 格式 只 


是 其 中 一 种 常见 的 解析 方式 ， 我 们 同样 可 以 直接 解析 展示 到 终端 上 或 者 以 行 的 形式 保存 在 普通 文件 中 。 下 面 是 解析 操作 的 入 口 : 












































Configuration conf = new Configuration(); 
try (PrintStream out = outputFile.equals("-") ? 
System.out : new PrintStream(outputFile, "UTF-8")) { 
// 根据 传 入 处 理 器 参数 的 不 同 ， 做 不 同 的 处 理 
switch (processor) { 
case "FileDistribution": 
long maxSize = Long.parseLong (cmd.getOptionValue ("maxSize", "0")); 
int step = Integer.ParseInt (cmd.getOptionValue ("step", "0")); 
new FileDistributionCalculator (conf, maxSize, step, out) .visit( 
new RandomAccessFile (inputFile, "r")); 
break; 
Case "XML": 
new PBImageXmlWriter (conf, out) .visit( 
new RandomAccessFile (inputFile, "r")); 
break; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











进入 其 中 PBlmageXmlWriter 对 象 的 visit 方 法 ， 首 先 会 进行 FileSummary 的 解析 : 





FileSummary summary = FSImageUtil.loadSummary (file); 














解析 summary 的 目的 是 要 获取 其 中 的 section 列 表 : 

















ArrayList<FileSummary.Section> sections = Lists.newArrayList (summary 
.getSectionsList ()); 








Section 的 概念 非常 的 重要 ， 每 个 Section 会 对 应 一 类 的 数据 。XML 格 式 文件 也 会 依赖 Section 进 行 每 段 XML 数 据 的 输出 。 从 Fslmage 中 解析 出 的 Section 有 下 面 几 类 (代码 部 分 省 略 ) : 














Switch (SectionName.fromString(s.getName())) { 

// 命名 空间 信息 

Case NS_INFO: 
break; 

// 权限 辅助 信息 

Case STRING TABLE: 
break; 一 

// INode 相 关 信 息 

case INODE : 
break; 

Case INODE REFERENCE: 
break; 

case INODE DIR: 
break; 一 

// 正在 构建 中 的 文件 信息 

Case FILES UNDERCONSTRUCTION: 
break; 

// 快照 相关 信息 

Case SNAPSHOT: 
break; 

Case SNAPSHOT DIFF: 
break; 

// 安全 管理 相关 的 信息 

Case SECRET MANAGER: 
break; 一 

// 缓存 管理 相关 信息 

Case CACHE MANAGER: 
break; 

default: 
break; 


上 





以 上 10 个 分 支 可 大 致 分 为 以 下 7 大 类 : 
“ 命名 空间 类 Section， 包 括 namespaceId、tollingUpgradeStartTime 等 类 型 的 变量 。 
' INode 相 关 Section， 包 含 了 文件 、 目 录 相 关 INode 的 信息 。 
“FileUnderConstructionSection 正 在 构建 中 的 文件 信息 。 
"SnapShot 快照 相关 信息 。 
“ SecretManaget 安 全 管理 相关 信息 。 
.CacheManager 缓 存 管理 相关 信息 。 


“StringTable 权 限 相关 的 信息 (辅助 其 他 Section 输 出 XML 信 息 ) 。 











具体 Section 里 面 对 应 有 哪些 信息 可 以 在 本 节 末 尾 的 镜像 解析 完 的 XML 文 件 样 本 链接 中 进行 查看 。 其 实 Section 本 质 上 并 不 保存 信息 ， 只 是 提供 了 偏 移 量 和 长 度 ， 最 终 获取 内 部 的 数据 还 是 得 从 镜像 文件 


的 输入 流 中 获取 ， 从 下 面 的 代码 就 可 以 得 出 这 样 的 结论 : 




















for (FileSummary.Section s : sections) { 
// 获取 Section 中 的 偏 移 量 信息 ， 并 将 位 置 定位 到 偏 移 量 处 
in.getChannel () .Position(s.getOffset ()); 
// 读 取 此 部 分 的 输入 文件 内 容 
InputStream is = FSImageUtil .wrapInputStreamForCompression (conf, 
summary.getCodec(), new BufferedInputStream (new LimitInputStream( 
fin, s.getLength()))); 








Switch (SectionName.fromString(s.getName())) { 


case NS_INFO: 
dumpNameSection (is); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





我 们 以 一 个 简单 的 解析 例子 来 看 XML 格式 的 内 容 是 怎么 被 输出 的 ， 以 Namesection 为 例 : 








private void dumpNameSection (InPutStream in) throws IOException { 
// 根据 给 定 的 局 部 输入 流 ， 解 析 成 具体 的 Section 对 象 
NameSystemSection s NameSystemSection.parseDelimitedFrom (in); 
/7 根 匡 解析 好 的 section 对 象 ， 进 行人 T 格 式 内 容 沿 给 出 
out.print ("<" + NAME SECTION NAME + ">"); 
© (NAME, SECTION NAMESPACE ID, s. Sens dara 
oma SECTION | GENSTAMPVI, s.getGenstampV1 ()) 
O(NAME : SECTION GENSTAMPV2, s.getGenstampV2()) 
oO (NAME : SECTION ( GENSTAMPV]1 _ LIMIT，s.getGenstampV1Limit () ) 
O(NAME : SECTION LAST ALLOCATED BLOCK_ID, 
getLastAllocatedBlockId () . 
© (NAME, SECTION TXID, s.getTransactionId()); 
out.print ("</" + NAME, SECTION NAME + ">\n"); 





原理 很 简单 ， 就 是 逐 行 地 输出 ， 额 外 拼装 成 XML 格式 。 到 此 Fslmage 文 件 的 解析 过 程 就 是 如 此 。 





6.1.3 ”Fslmage 的 反 解 析 








在 本 节 开 头 部 分 已 经 提 过 ，Fslmage 的 反 解析 是 最 近 社区 完成 的 一 个 新 功能 。 这 里 的 FslImage 























反 解 析 指 的 是 对 解析 后 的 xml 文 件 的 逆 解 析 过 程 ， 重 新 生成 Fslmage 二 进 制 文件 。 与 以 往 只 全 


无 法 直接 查阅 的 Fslmage 文 件 相 比 ， 保 存 解析 后 的 xml 文 件 显然 非常 方便 于 用 户 的 使 用 。 反 解析 核心 类 叫做 OfflinelmageReconstructor， 这 个 类 目前 需 

















版 本 的 源码 中 并 不 存在 。 下 面 是 入 口 处 理 方法 : 





要 获取 hadoop-trunk 分 支 代码 才能 看 到 ， 


保存 纯粹 的 




















前 发 布 





try (PrintStream out = outputFile.equals ("-") ? 
System.out : new PrintStream( oh utFile, "UTF-8")) { 
/7 检 本 有 信和 启 只 保罗 天涯 交 闫 过 做 分 类 处 理 


Switch (processor) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 


// 反 解 析 XML 文 件 过 程 
Case "ReverseXML": 
try { 
OfflineImageReconstructor.run (inputFile, outputFile); 
} catch (Exception e) { 
System.err.Println("OfflineImageReconstructor failed: " + 
e.getMessage ()); 
e.printstackTrace (System.err); 
System.exit (1); 


break; 





接着 进入 OfflinelmageReconstructor 的 run 方 法 : 





public static void run (String inputPath, String outputPath) 

throws Exception { 

MessageDigest digester = MD5Hash.getDigester(); 
FileOutputStream fout = null; 
File foutHash = new File(outputPath + " .md5") 7 
Files.deleteIfExists (foutHash.toPath()); // delete any .md5 file that exists 
CountingOutputStream out = null; 
FileInputStream fis = null; 
InputStreamReader reader = null; 

try { 
// 如 果 目 标 输 出 路 径 已 存在 ， 则 进行 删除 
Files.deleteIfExists (Paths .get (outputPath) ) 7 
fout = new FileOutputStream (OutPutPath) 7 
/7 根据 入 六 中 生得 到 名 和 流 等 
fis = new FileInPputStream(inputPath) 
reader = new InputStreamReader (fis, Charset.forName ("UTF-8")); 
out = new CountingOutputStream( 
new DigestOutputStream( 
new BufferedOoutputStream(fout), digester)); 
OfflineImageReconstructor oir = 
new OfflineImageReconstructor (out, reader); 

// 进行 镜像 文件 反 解析 的 过 程 
oOir.ProcessXml (); 

} finally { 
IOUtils.cleanup (LOG, reader, fis, out, fout); 

上 

// Write the md5 file 

MD5PFileUtils.saveMD5File (new File (outputPath), 

new MD5Hash (digester.digest ())); 








以 上 代码 主要 做 了 以 下 几 件 事情 : 








“ 先 判断 之 前 是 否 已 经 存在 目标 文件 ， 如 果 存 在 则 进行 删除 。 
“ 在 内 部 进行 了 OffineImageReconstructor 对 象 的 构建 。 
“ 然后 进行 XML 文件 的 处 理 。 


然后 进入 OfflinelmageReconstructor 的 构造 函数 ， 里 面 会 做 哪些 初始 化 操作 呢 ? 代码 如 下 : 


private OfflineImageReconstructor (CountingOutputStream out, 
InputStreamReader reader) throws XMLStreamException { 
this.out = out; 
XMLInputFactory factory = XMLInputFactory.newInstance () 7 
this .events = factory.createXMLEventReader (reader); 
this.sections = new HashMap<>(); 
this.sections.put (NameSectionProcessor.NAME, new NameSectionProcessor()); 
this.sections.put (INodeSectionProcessor.NAME, new INodeSectionProcessor()); 
this.sections.put (SecretManagerSectionProcessor .NAME, 
new SecretManagerSectionProcessor ()); 
this.sections.put (CacheManagerSectionProcessor .NAME, 
new CacheManagerSectionProcessor ()); 
this.sections.put (SnapshotDiffSectionProcessor .NAME, 
new SnapshotDiffSectionProcessor ()); 
this.sections.put (INodeReferenceSectionProcessor.NAME, 
new INodeReferenceSectionProcessor()); 
this.sections.put (INodeDirectorySectionProcessor .NAME, 
new INodeDirectorySectionProcessor()); 
this.sections.put (FilesUnderConstructionSectionProcessor.NAME, 
new FilesUnderConstructionSectionProcessor ()); 
this.sections.put (SnapshotSectionProcessor.NAME, 
new SnapshotSectionProcessor()); 
this.isoDateFormat = PBImageXxmlWriter.createSimpleDateFormat (); 





在 这 里 出 现 了 很 多 的 SectionProcessor 对 象 ， 这 是 对 应 于 PBlImageXmlWriter 类 中 的 9 大 Section 的 。 但 是 好 像 stringTable 没 有 对 应 到 ， 在 下 文中 将 会 提 到 。 








Case STRING TABLE: 
loadSstringTable (is); 
break; 





那么 这 些 SectionProcessor 对 象 是 如 何 解 析 XML， 然 后 将 信息 写 入 FslImage 的 输出 文件 的 呢 ? 以 NameSectionProcessor 为 例 : 





private class NameSectionProcessor implements SectionProcessor { 
static final String NAME = "NameSection"; 


QOverrigde 

Public void process() throws IOException { 
Node node = new Node(); 
loadNodeChildren (node, "NameSection fields"); 
NameSystemSection.Builder b = NameSystemSection.newBuilder () 7 
Integer namespaceId = node.removeChildInt (NAME SECTION NAMESPACE ID); 
if (namespaceId null) { 过 加 

throw new IOException ("<NameSection> is missing <namespaceId>") 7 


} 
// 将 相关 的 值 设 入 Section 的 Builder 对 象 中 
Pb.setNamespaceId (namespaceId); 
Long lval = node.removeChildLong (NAME SECTION GENSTAMPV1); 
if (lval != null) { 
b.setGenstampV1 (lval); 
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node.verifyNoRemainingKeys ("NameSection"); 
// 用 Section 的 Builder 对 象 来 创建 Section 
NameSystemSection s = b.build(); 
if (LOG.isDebugEnabled()) { 
LOG.debug (SectionName.NS_INFO.name () + " writing header: {" + 
TextFormat .printToString(s) + "}"); 


} 

// 将 Section 对 象 内 容 写 出 到 输出 流 文件 中 
s.writeDelimitedTo (out); 

recordSectionLength (SectionName.NS_INFO.name ()); 





以 上 的 过 程 可 以 归纳 为 如 下 步骤 : 


1) 从 XML 文件 中 解析 数据 加 载 到 Node 节 点 对 象 : 





loadNodeChildren (node, "NameSection fields"); 





2) 从 Node 对 象 中 通过 key 名 称 获取 对 应 的 值 并 移 除 原 有 key-value 对 : 





Long lval = node.removeChildLong (NAME SECTION GENSTAMPV1); 





3) 检查 Node 对 象 是 否 已 经 没有 剩余 的 key: 





node.verifyNoRemainingKeys ("NameSection"); 





4) 将 解析 好 后 的 信息 写 入 目标 镜像 文件 : 





s.writeDelimitedTo (out); 








其 他 SectionProcessor 的 处 理 与 此 类 似 ， 这 里 就 不 进行 多 余 的 介绍 了 。 回 到 刚刚 提 到 的 问题 ， 为 什么 stringTable 没 有 对 应 的 processor 呢 ?因为 在 生成 的 Fslmage 中 会 重新 进行 构造 : 














int registerStringId(String str) throws IOException { 
Integer id = stringTable.get (str); 
if (id != null) { 
return id; 
} 
int latestId = latestStringId7 
if (latestId >= Oxlffffff) { 
throw new IOException("Cannot have more than 2**25 " 十 
"strings in the fsimage, because of the limitation on "+ 
"the size of string table IDs."); 


和 

// 将 iq 值 加 入 stringTable 中 
stringTable.put (str, latestId); 
latestStringId++; 

return latestId; 











在 与 权限 相关 的 操作 中 会 调用 到 此 方法 : 











private long PermissionXmlToU64 (String Perm) throws IOException { 
String components[] = perm.split(":"); 
if (components.length != 3) { 
throw new IOException ("Unable to parse permission string " + perm + 
":; expected 3 components, but only had " + components.length); 
于 
String userName = components[0]; 
String groupName = components[1]; 
String modeString = components[2]; 
// 将 以 上 名 称 写 入 stringTable 
long userNameId = registerStringId (userName); 
long groupNamelId = registerStringId (groupName); 
long mode = new FsPermission (modeString) .toShort (); 
return (userNameId << 40) | (groupNameld << 16) | moge; 





在 OfflinelmageReconstructor 中 的 processXm| 方 法 中 ， 采 取 了 循环 逐个 解析 的 方式 进行 Section 的 处 理 : 





Private void ProcessXml () throws Exception { 
LOG.debug ("Loading <fsimage>."); 
expectTag ("fsimage", false); 
// 读 入 镜像 文件 的 version 版 本 号 
readVersion () 7 
// 在 镜像 文件 中 开始 写 入 magic 数 字 信 息 
out .write (FSImageUtil .MAGIC HEADER); 
// 准备 写 出 一 系列 的 Section 信 息 
SectionStartOffset = FSImageUtil .MAGIC HEADER.1length; 
final HashSet<String> unprocessedSections = 

new HashSet<> (sections.keySet ()); 





// 循环 遍历 处 理 Section， 直 到 Section 都 处 理 完毕 

while (!unprocessedSections.isEmpty()) { 
XMLEvent ev = expectTag("[section header]", true); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
SectionProcessor sectionProcessor = sections.get (sectionName); a 


if (sectionProcessor == null) { 
throw new IOException ("Unknown FSImage section " + sectionName + 
". Valid section names are [" + 


StringUtils.join(", ", sections.keySet()) + "]"); 
} 

UnprocessedSections.remove (sectionName); 
sectionProcessor.process (); 


// 写 出 stringTable 的 Section 信 息 
writestringTableSection(); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





while 循 环 结束 之 后 ， 最 后 会 把 stringTable 再 次 写 入 。 





区 











Fslmage 的 解析 与 反 解析 的 过 程 具有 非常 强 的 对 称 性 。 图 6-1 所 示 为 FslImage 的 解析 与 反 解析 流程 。 
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重 构 到 fsImage 文件 
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6-1 FsImage 的 解析 与 反 解析 流程 














6.1.4 ”HDFS 镜 像 文 件 的 解析 与 反 解析 命令 





HDFS 关 于 镜像 解析 的 命令 主要 以 hdfs oiv 打 头 ，oiv 为 OfflinelmageView 的 缩写 。 解 析 与 反 解析 在 这 里 的 区 别 只 是 处 理 器 的 不 同 。 目 前 总 共有 以 下 5 大 处 理 器 : 





“XML 


* ReverseXML 


* FileDistribution 


“Web 


* Delimited 








调用 命令 如 下 : 











Usage: bin/hdfs oiv -p XML/ReverseXML -i INPUTFILE -o OUTPUTFILE 








inputFile 和 outputFile 为 必 填 参 数 。 如 果 想 看 其 他 参数 ， 可 以 输入 以 下 命令 进行 查阅 : 





bin/hdfs oiv -h 








其 中 ，hdfs oiv 命 令 除 了 上 面 提 到 的 将 镜像 文件 解析 为 可 读 的 XML 文件 之 外 ， 还 有 一 个 很 实用 的 分 析 文件 目录 的 功能 。 它 能 根据 镜像 文件 ， 离 线 计算 出 HDFs 中 所 有 文件 和 目录 数 ， 并 且 能 够 对 文件 做 大 
小 分 类 ， 统 计 出 在 各 个 大 小 区 间 内 的 文件 数量 ， 借 此 可 以 判断 集群 中 是 否 存 有 大 量 的 小 文件 。 文 件 大 小 分 析 功 能 需要 用 -p FileDistribution 的 处 理 器 ， 我 们 还 可 以 根据 自己 的 需要 限定 一 个 区 间 大 小 step 和 最 
大 上 限 值 大 小 maxSize， 使 用 命令 如 下 : 



































bin/hdfs oiv -P FileDistribution -i INPUTFILE -Oo OUTPUTFILE 



































使 用 此 命令 ， 可 以 免 去 用 户 额外 编写 java 程 序 去 做 HDFS 文 件 扫描 处 理 的 过 程 。 通 过 用 户 程序 的 方式 去 分 析 HDFS 文 件 目录 情况 会 造成 对 NameNode 大 量 文件 信息 的 请 求 。 另 外 笔者 在 工作 中 使 用 此 工 . 
时 发 现 了 两 个 比较 影响 用 户 体验 的 问题 : 



























































“ 解析 镜像 文件 有 时 会 出 现 数组 越界 ， 继 而 导致 分 析 程序 退出 的 现象 。 后 来 经 过 调试 程序 ， 笔 者 发 现 这 样 的 情况 发 生 在 maxSize 无 法 完全 整除 step 值 的 特殊 情况 ， 随 后 笔者 向 社区 提交 了 issue， 并 进行 了 
解决 ，JIRA 编 号 HDFS-10691。 


: FileDistribution 处 理 器 解析 结果 可 读 性 较 差 ， 无 法 让 用 户 直观 地 理解 它 的 意思 。 于 是 笔者 对 其 进行 了 优化 ， 在 FileDistribution 处 理 器 中 新 增 了 -format 和 参数 来 可 视 化 输出 的 结果 ， 详 细 内 容 可 见 JIRA: 
HDFS-10778。 





用 hdfs oev 命 令 分 析 editlog 文 件 





与 hdfs oiv 命 令 类 似 ，HDFS 同 样 提供 了 分 析 editlog 日 志文 件 的 工具 命令 : hdfs oev。oev 是 OfflineEditsViewer 的 缩写 ， 在 hdfs oev 命 令 中 ， 可 以 分 析出 指定 editlog 文 件 中 各 个 操作 记录 类 型 以 及 相应 
的 计数 值 ， 详 细 的 命令 使 用 方法 可 以 输入 hdfs oev 进 行 查看 。 

















希望 本 节 内 容 能 够 对 大 家 有 所 帮助 ， 对 Fslmage 以 及 hdfs oiv 有 更 多 了 解 。 在 学 习 OfflinelmageReconstructor 源 码 的 同时 ， 笔 者 发 现 了 其 中 部 分 可 以 优化 的 地 方 ， 向 社区 提交 了 JIRA: HDFS- 
9951 (Use string constants for XML tags in OfflinelmageReconstructor) ， 目 前 已 被 社区 接受 。 有 兴趣 的 同学 ， 可 以 查看 此 J|RA。 最 后 附 上 一 个 镜像 文件 解析 好 的 XML 格 式 文件 样 例 (可 能 部 分 人 并 
没有 看 过 HDFS 的 镜像 文件 里 面 到 底 保 存 了 什么 样 的 内 容 ) ， 方 便 大 家 对 照 源码 学 习 。 





























镜像 文件 的 XML 解析 文件 样本 链接 如 下 : https://github.com/linyiqun/open-source-patch/blob/master/hdfs/others/hdfs-fsimage/fsimageSample.xml。 


6.2 DataNode 数 据 处 理 中 心 DataXceiver 























在 DataNode 中 ， 包 含 着 一 个 数据 处 理 中 心 类 : DataXceiver。 数 据 读 写 的 所 有 操作 都 会 经 过 此 类 。 用 简单 的 一 句 话 来 概括 它 的 作用 : DataXceiver 个 数 的 多 少 ， 在 一 定 程度 上 能 反映 出 此 节点 的 忙碌 程 
度 。 本 节 将 为 大 家 介绍 DataXceiver 内 部 的 过 程 调用 ， 以 及 普通 的 文件 读 写 操作 是 如 何在 DataXceiver 中 调用 的 。 










































































我 们 从 大 的 层面 往 小 涪 ， 你 就 知道 它 有 多 重要 了 。 我 们 使 用 Hadoop 系 统 ， 最 看 重 的 是 两 个 字 : 存储 。 存 储 的 过 程 中 ， 什 么 又 是 最 看 重 的 呢 ? 那 当然 是 数据 了 。 而 这 些 数据 都 是 存在 于 各 个 DataNode 
之 上 的 。 所 以 掌控 DataNode 读 写 操作 的 服务 就 显得 尤为 重要 了 。 而 这 个 控制 中 心 就 在 DataXceiver 中 。 























6.2.1 _ DataXceiver 的 定义 和 结构 








DataXceiver 是 干什么 用 的 呢 ， 很 多 人 只 知 DataNode， 而 不 知 另外 一 个 很 重要 的 线程 服务 DataXceiver。 在 HDFS 中 对 于 DataXceiver 的 解释 如 下 : 

















// 处 理 输入 、 输 出 数据 流 的 线程 类 
Class DataXceiver extends Receiver implements Runnable { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


笔者 的 个 人 理解 是 数据 流 的 处 理 中 心 。DataXceiver 线 程 数 的 多 少 在 一 定 程度 上 能 反映 出 一 个 节点 的 忙碌 程度 。DataXceiver 这 个 类 中 包含 的 变量 和 方法 还 是 比较 多 的 ， 这 里 不 大 建议 读者 逐 行 详细 地 去 
阅读 内 部 的 代码 。 我 们 去 学 习 一 个 机 制 、 原 理 的 时 候 ， 明白 的 是 结构 。 比 如 我 们 现在 要 去 学 习 DataXceiver 这 个 类 ， 我 们 的 目标 是 去 了 解 这 个 类 主要 做 了 哪些 操作 ， 上 游 被 哪些 对 象 调用 ， 下 游 又 调 有 
了 哪些 类 ， 具 体 的 代码 细节 等 碰 到 具体 的 问题 时 再 去 分 析 即 可 ， 否 则 可 能 会 被 里 面 复 杂 的 逻辑 绕 晕 。 毕 况 Hadoop 是 一 个 成 熟 的 分 布 式 程序 ， 不 是 一 时 半 会 能 够 立刻 理解 的 。 
















































































为 了 更 好 地 理解 这 个 “数据 处 理 中 心 。， 我 们 需要 去 了 解 这 个 类 的 整体 结构 ， 在 此 之 前 不 妨 浏览 一 下 其 中 的 内 部 方法 。 图 6-2 所 示 为 DatxXceiver 内 部 的 处 理 方法 。 











@ arun() : void 

®@ srequestShortCircuitFds(ExtendedBlock, Token<BlockTokenldentifier>, Slotld, int, boolean) 
© ~releaseShortCircuitFds(Slotld) : void 

回 sendShmErrorResponse(Status, String) : void 

目 SendShmSuccessResponse({DomainSocket, NewShmlnfo) : void 

@ srequestShortCircuitShm(String) : void 

二 releaseSocket() : void 

© ,readBlock(ExtendedBlock, Token<BlockTokenidentifier>, String, long, long, boolean, Cach 
© ~ WriteBlock(ExtendedBlock, StorageType, Token<BlockTokenldentifier>, String, Datanodeln 
© ,transferBlock(ExtendedBlock, Token<BlockTokenldentifier>, String, Datanodelnfoll, Storac 
回 calcPartialBlockChecksum(ExtendedBlock, long, DataChecksum, DatalnputStream) : MD5 
© ,blockChecksum(ExtendedBlock, Token<BlockTokenldentifier>) : void 

© .copyBlock(ExtendedBlock, Token<BlockTokenldentifier>) ; void 

@ replaceBlock(ExtendedBlock, StorageType, Token<BlockTokenldentifier>, String, Datanod 
国 elapsed0 ; long 

国 SendResponse(Status, String) ; void 

日 5 writeResponse(Status, String, OutputStream) : void 

回 WriteSuccessWithChecksumlnfolBlockSender DataOutputStream) : void 

回 incrDatanodeNetworkErrors() : void 

目 CcheckAccess(OutputStream, boolean, ExtendedBlock, Token<BlockTokenldentifier>, Op, / 


Press ‘$30' to show inherited members 








图 6-2 ”DataXceiver 内 部 方法 操作 





首先 ， 这 是 一 个 线程 服务 ， 执 行 入 口 是 run 方 法 。 执 行 run 方 法 。 我 们 可 以 找到 与 之 关联 的 操作 : 




















public void run() { 
int opsProcessed = 0; 
Op op = null; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// 在 下 面 的 循环 中 周期 性 处 理 请 求 
do { 

updateCurrentThreadName ("Waiting for operation #" + (opsProcessed + 1)); 


try { 
if (opsProcessed != 0) { 
assert dnConf.socketKeepaliveTimeout > 0; 
Peer.setReadTimeout (dnConf .socketKeepaliveTimeout); 
} else { 
peer.setReadTimeout (dnConf .socketTimeout); 


// 读 取 请 求 操作 码 
op = readop (); 
catch (InterruptedIOException ignored) { 
// 等 待 客户 端 RPC 请 求 超时 
break; 
catch (IOException err) { 
// EOFException 异 常 处 理 
if (opsProcessed > 0 && 
(err instanceof EOFException || err instanceof ClosedChannelException)) { 
if (LOG.isDebugEnabled()) { 
L0G.debug ("Cached " + Peer + " closing after " + opsProcessed + " ops");zhu 


} else { | 
// 增加 网 络 IO 异常 计数 
incrDatanodeNetworkErrors () 7 
throw err; 
} 
break; 
} 


// 重新 设置 超时 时 间 
if (opsProcessed != 0) { 
peer. setReadTimeout (dnConf .socketTimeout); 





. 


OPStartTime = monotonicNow(); 
// 处 理 请 求 操作 码 
ProcessOp (op) 7 
++opsProcessed; 
} while ((peer != null) && 
(!peer.isClosed() && dnConf.socketKeepaliveTimeout > 0)); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 run 方 法 中 间 的 主 循环 方法 中 ， 可 以 看 到 一 次 readOp 操 作 ， 对 应 的 是 一 次 processOp 操 作 。Op 的 意思 是 操作 码 ，readOp 方 法 会 从 输入 流 中 读 取 操作 码 : 





// 读 取 Op 操 作 码 方法 
protected final Op readop() throws IOException { 
final short version = in.readShort (); 
if (version != DataTransferProtocol .DATA TRANSFER VERSION) { 
throw new IOException( "Version Mismatch (Expected: " + 
DataTransferProtocol .DATA TRANSFER VERSION + 


", Received: " + version +" )"); 


} 
// 从 输入 流 中 读 取 操 作 码 


return Op.read (in); 





而 processOp 方 法 则 会 进行 操作 码 的 判断 处 理 ， 主 要 分 为 以 下 几 类 操作 码 的 判断 : 





// process OP 操作 码 
protected final void ProcessOP (OP op) throws IOException { 
switch(op) { 
// 读 取 块 的 处 理 
Case READ BLOCK: 
opReadBlock (); 
break; 
// 写 块 的 处 理 
case WRITE BLOCK: 
opWriteBlock (in) ; 
break; 
// 取代 块 的 处 理 ，Balancer 数 据 平衡 的 时 候 会 调用 到 
Case REPLACE BLOCK: 
opReplaceBlock (in) 
break; 
// 复制 块 的 处 理 ，Balancez 数 据 平衡 的 时 候 会 调用 到 
Case COPY BLOCK: 
opCopyBlock (in) 7 
break; 
// 读 取 校 验 和 的 处 理 
Case BLOCK CHECKSUM: 
opBlockChecksum (in); 


eak; 
// 传输 数据 块 的 处 理 
Case TRANSFER BLOCK: 
opTransferBlock (in); 
break; 
// 以 下 3 类 处 理 均 与 Shortcircuit (短路 读 ) 相关 
Case REQUEST SHORT CIRCUIT FDS: 
opRequestShortCircuitFds (in); 
break; 
Case RELEASE SHORT CIRCUIT FDS: 
opReleaseShortCircuitFds (in); 
break; 
Case REQUEST SHORT CIRCUIT SHM: 
opRequestShortCircuitShm(in); 
break; 
default: 
throw new IOException ("Unknown op " + op + " in data stream"); 
} 
人 





br 








总 共 9 种 类 型 ， 对 应 着 9 种 处 理 方法 。 到 此 ，DataXceiver 的 基本 结构 慢 慢 清晰 了 ， 


SendOp 






DataXceiver 





左上 方 的 Sender 对 象 在 下 文中 会 具体 讲述 ， 此 处 可 以 先 忽略 。 


如 图 6-3 所 示 。 
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图 6-3 ”DataXceivet 的 基本 处 理 结构 
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repLaceBlock 


6.2.2 DataXceiver 下 游 处 理 方法 








从 上 文中 的 结构 图 中 我 们 看 到 了 处 理 操作 码 的 9 个 方法 和 2 个 回复 方法 。 这 9 个 方法 可 以 大 致 分 为 两 大 类 。 第 一 类 ， 普 通读 写 块 的 操作 方法 。 划 分 到 普通 读 写 块 方法 的 有 readBlock、writeBlock、 
transferBlock、copyBlock、replaceBlock 和 blockChecksum， 剩 下 的 一 类 方法 则 属于 ShortCircuit (短路 读 ) 相关 的 方法 。 下 面 对 这 些 方法 做 场景 分 析 :: 


























1.readBlock 














方法 名 已 经 表明 了 此 方法 的 操作 了 ， 自 然 是 读 取 块 信息 的 操作 ， 一 般 用 于 远程 读 或 者 本 地 读 操作 。 











2.writeBlock 





写 块 操 作 ， 将 参数 传 入 的 数据 块 写 入 目标 节点 列表 中 。 


3.transferBlock 


传输 指定 副本 到 目标 节点 列表 中 。 


4.copyBlock 














拷贝 块 信息 数据 ， 与 readBlock 原 理 类 似 ， 都 用 到 了 BlockSender 的 send 方 法 。 














5.replaceBlock 











replaceBlock 在 DataXceiver 中 更 接近 的 意思 是 moveBlock， 此 操作 一 般 会 在 数据 平衡 的 时 候 被 调用 到 。 














6.blockChecksum 


从 文件 元 信息 头 部 读 取 校 验 和 数据 。 











这 里 要 特地 将 ShortCircuit (短路 读 ) 的 几 个 方法 单独 分 到 一 个 模块 中 ， 因 为 短路 读 机 制 是 HDFS 在 后 面 的 版 本 中 才 引 入 的 概念 ， 可 能 有 些 人 还 不 大 了 解 ， 这 里 简单 介绍 一 下 这 方面 的 内 容 。 



































6.2.3 ShortCircuit 








在 早 些 时 候 ，Hadoop 为 了 能 让 数据 处 理 更 加 高 效 ， 尽 可 能 让 数据 维持 在 本 地 ， 以 此 避免 大 量 的 远程 读 操作 。 尽 管 本 地 读 的 比例 确实 提升 了 ， 但 还 不 是 最 优 的 。 因 为 虽然 数据 是 在 本 地 ， 但 是 每 次 客户 
端 读 取 数 据 ， 还 是 需要 走 DataNode 这 一 层 ， 在 其 间 还 是 会 走 网 络 通 信 的 模块 ， 能 不 能 以 类 似 于 直接 读 取 本 地 文件 系统 的 方式 去 读本 地 的 数据 呢 ? ShortCircuit 就 是 源 自 于 这 个 想法 而 诞生 的 。 


















































1.ShortCircuit 本 地 读 的 实现 














HDFSs 采 用 了 Linux 操 作 系统 中 的 Unix Domain Socket 技 术 来 实现 ShortCircuit 功 能 。ShortCircuit 是 一 种 进程 间 通 信 的 方式 ， 很 重要 的 一 个 特性 是 可 以 在 进程 间 传 递 文件 描述 符 ， 借 此 来 进行 进程 间 的 
通信 ， 从 而 实现 了 本 地 读 。 关 于 ShortCircuit 本 地 读 更 多 细节 的 文章 可 以 阅读 cloudera 官 网 上 的 一 篇 文章 : “How Improved Short-Circuit Local Reads Bring Better Performance and Security to 
Hadoop”。 




















2.ShortCircuit 机 解 
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在 HDFS 中 用 的 是 共享 内 存 片 段 (short-circuit memory segments) 来 实现 数据 的 读 操 作 。DFSClient 客 户 端 通过 shortCircuit 机 制 实 现 本 地 读 的 简要 过 程 如 下 : 
1) DFSClient 客 户 端 从 DataNode 请 求 共享 内 存 片段 。 

2) ShortCircuitRegistry 注 册 对 象 会 产生 并 管理 这 些 内 存 对 象 。 

3) 在 本 地 读 之 前 ，DFSClient 客 户 端 会 向 DataNode 请 求 需要 的 文件 描述 符 ， 对 应 的 就 是 requestShortCircuitFds 方 法 。 


4) 如 果 一 次 本 地 读数 据 完成 之 后 ， 相 应 地 会 执行 releaseShortCircuitFds 释 放 操作 。 


6.2.4 DataXceiver 的 上 游 调 用 

















DataXceiver 的 上 游 调 用 指 的 是 Op 操作 码 的 输入 方 ， 通 过 寻找 Op 操作 码 的 调用 位 置 可 以 发 现 都 是 来 自 于 同一 个 对 象 类 : Sender。 其 中 以 COPY_BLOCK 操 作 码 为 例 : 






































Override 
Public void copyBlock (final ExtendedBlock blk, 
final Token<BlockTokenIdentifier> blockToken) throws IOException { 
OpCopyBlockProto proto = OpCopyBlockProto.newBuilder () 
.SetHeader (DataTransferProtoUtil .buildBaseHeader (blk, blockToken)) 


.build(); 
// 发 送 拷贝 块 的 操作 请 求 
send (out, Op.COPY BLOCK, proto); 
k 


























Sender 类 中 的 剩余 8 个 方法 均 与 DataXceiver 中 的 方法 相对 应 。 现 在 就 可 以 很 好 地 解释 图 6-3 中 Sender 存 在 的 原因 了 。Sender 对 象 虽然 是 操作 码 的 直接 传 入 类 ， 但 并 不 是 方法 最 初始 的 调用 方 ， 我 们 需 
要 从 这 个 点 往 上 继续 寻找 ， 找 到 最 开始 的 触发 者 ， 图 6-4 显 示 了 最 初始 的 调用 方 。 













































































辐 6-4 中 的 Dispatcher 类 是 用 在 Balancer 操 作 中 的 。 如 上 图 所 显示 的 ， 真 正 读 写 数据 的 发 起 方 是 我 们 经 常 碰 到 的 PDFSClient、DFSOutputSstream 和 BlockReader 这 些 对 象 类 。 至 此 ，DataXceiver 的 上 游 
调用 以 及 下 游 处 理 就 完全 打通 了 。 
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6-4 Sender 与 DataXceiver 的 关系 图 

















6.2.5 DataXceiver 与 DataXceiverServer 


提 到 DataXceiver 就 不 得 不 提 DataXceiverServer。DataXceiverServer 会 保存 每 次 新 启动 的 DataXceiver 线 程 。 在 它 的 主 循环 方法 中 ， 会 进行 DataXceiver 的 创建 : 





QOverride 
public void run() { 
Peer peer = null; 


while (datanode.shouldRun && !datanode.shutdownForUpgrade) { 
try { 
peer = peerServer.accept (); 


// Make sure the xceiver count is not exceeded 
// 获取 DataNode 目 前 已 有 的 DataXceiver 个 数 ， 保 证 DataXceiver 个 数 不 超 过 上 限 
int curXceiverCount = datanode.getXceiverCount (); 
if (curXceiverCount > maxXceiverCount) { 
throw new IOException("Xceiver count " + curXceiverCount 
+ " exceeds the limit of concurrent xcievers: " 
+ maxXceiverCount); 


} 
// 启动 新 的 DataXceiver 线 程 服务 
new Daemon (datanode.threadGroup, 
DataXceiver.create (peer, datanode, this)) 
.Start (); 
} catch (SocketTimeoutException ignored) { 





随后 DataXceiver 会 加 入 DataXceiverServer 的 map 对 象 中 : 





public void run() { 
int opsProcessed = 0; 


Op op = null; 
try { 
dataXceiverServer .addPeer (peer, Thread.currentThread(), this); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
synchronized void addPeer (Peer peer, Thread t, DataXceiver xceiver) 
throws IOException { 
if (closed) { 
throw new IOException ("Server closed."); 


} 

// 将 DataXceiver 对 象 加 入 map 中 进行 保存 
Peers .put (peer, t); 
peersXceiver.put (peer, xceiver); 





所 以 DataXceiverServer 与 DataXceiver 的 关系 可 以 说 是 包含 与 被 包含 的 关系 。 


6.3 ”HDFS 令 $ 近 信息 块 : BlocklnfoContiguous 


在 HDFS 中 ， 数 据 的 存储 是 以 块 的 形式 存在 的 。 而 每 个 块 的 默认 副本 数 是 3 个 ， 于 是 在 HDFS 中 会 存在 3 个 相同 的 块 副 本 分 布 在 不 同 的 DataNode 节 点 上 。 这 些 相同 块 的 副本 信息 由 HDFS 邻 近 信息 块 
(BlocklnfoContiguous) 所 包含 。 在 BlocklnfoContiguous 类 中 ， 这 些 副 本 块 信息 被 巧妙 地 组 织 ， 以 此 节省 出 更 多 的 内 存 空间 。 本 节 我 们 将 要 全 面 地 学 习 BlocklnfoContiguous 类 ， 了 解 它 的 作用 、 设 计 
原理 以 及 其 内 部 各 式 各 样 的 链表 操作 。 


























来 寻找 副本 块 的 直接 信息 

















的 源码 版 本 是 hadoop-2.7.1。 在 此 版 本 中 ，BlocklnfoContiguous 类 














在 最 新 的 hadoop-trunk 的 代码 中 这 个 类 已 经 做 了 比较 大 的 改动 ， 所 以 这 里 笔者 要 说 明 一 下 本 节 所 使 
同时 它 也 包含 了 自身 块 的 详细 信息 。 在 官方 的 源码 中 对 BlocklnfoContiguous 的 解释 如 下 : 


类 ， 它 的 内 部 包含 了 针对 某 个 块 的 所 有 副本 块 位 置信 息 ， 





// 此 类 包含 了 给 定 块 的 具体 信息 ， 同 时 包含 了 此 块 其 余 副 本 的 位 置信 息 
Q@InterfaceAudience.Private 
public class BlockInfoContiguous extends Block 

implements LightWeightGSet.LinkedElement { 


在 BlocklnfoContiguous 类 中 ， 有 两 个 关键 的 内 部 对 象 : BlockCollection 和 triplets。 前 者 保存 了 类 似 副 本 数 、 副 本 位 置 等 一 些 信息 ， 而 triplets 对 象 数 组 则 是 本 节 的 一 个 重点 。 所 以 下 面 详细 地 分 析 





triplets 对 象 数 组 的 设计 结构 和 思想 。 


6.3.1 triplets 对 象 数组 
triplets 对 象 初始 化 的 时 候 是 一 个 Object 对 象 数组 ， 但 是 在 赋值 的 时 候 ， 会 存储 两 类 对 象 。 以 下 是 triplets 数 组 变量 声明 : 





private Object[] triplets; 





通过 官方 源码 的 注释 ， 我 们 可 以 归纳 出 下 面 几 点 信息 : 
， 一 般 存储 的 节点 数 视 副 本 系数 而 定 。 


信息 ，triplets[3*i+2] 保 存 的 则 是 后 一 个 块 对 象 的 信息 ， 而 保存 块 信息 对 象 


“ 对 于 当前 块 的 信息 ， 块 存在 于 多 个 节点 位 置 中 ， 假 如 存储 于 i 个 节点 ， 则 triplets 对 象 数组 大 小 就 是 3 上 i 个 





对 triplets 每 3 个 为 一 单位 的 数组 来 说 ，ttiplets[3 基 保存 的 是 节点 位 置信 息 ，ttiplets[31+1] 保 存 的 是 此 节点 位 置 中 前 一 个 块 对 象 的 
图 6-5 所 示 。 











JDK 自 带 的 像 LinkList 这 样 的 链表 结构 。BlocklnfoContiguous 内 部 结构 如 




















的 类 同样 是 BlockInfoContiguous。 
所 以 我 们 可 以 稍稍 地 想象 一 下 ， 这 其 实 是 一 个 “巨大 的 链表 ”。 但 是 HDFS 为 了 更 高 效 地 使 用 内 存 ， 并 没有 采用 
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6-5 BlockInfoContiguous 结 构图 











Datanodestoragelnfo1、2、3 是 当前 块 存储 的 节点 ， 所 以 triplets 的 长 度 是 根据 副本 数 进 行 初始 化 的 : 





// 构造 一 个 实例 对 象 
public BlockInfoContiguous (short replication) 1{ 
this.triplets = new Object[3*replication]; 


this.bc = null; 
告 构 如 图 6-6 所 示 。 





bE: 





每 个 节点 上 会 存储 大 量 的 块 ， 通 过 块 的 下 一 个 块 或 前 一 个 块 ， 我 们 可 以 遍历 完 节点 上 的 所 有 块 。 在 每 个 DataNodeStoragelnfo 中 ， 所 持 有 块 的 关联 结构 如 


New Block 


DatanodeStorageInfoA DatanodeStorageInfoB 


list insert 


加 块 
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| = | previousBlock nextBlock  .。.。 





























6-6 ”DataNodeStorageInfo 上 的 块 关 联 


这 里 的 head 头 块 ， 对 应 的 是 DataNodeStoragelnfo 中 的 blocklist 对 象 : 





Private volatile BlockIinfoContiguous blockList = null; 











图 6-6 中 同一 个 节点 中 的 块 与 块 之 间 的 连接 关系 如 图 6-7 所 示 。 











DataNode 上 关于 块 的 操作 都 会 在 它 所 维护 的 块 列 表 中 进行 操作 。 
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图 6-7 节点 内 的 块 关系 


6.3.2 BlocklnfoContiguous 的 链表 操作 








DataNode 上 的 块 的 添加 删除 动作 对 照 过 来 就 是 BlocklnfoContiguous 的 链表 操作 。 其 中 的 操作 主要 分 为 两 类 : 一 个 是 addBlock 添 加 块 的 操作 ， 另 外 一 个 是 removeBlock 移 除 块 的 操作 。 这 两 个 方法 都 





定义 在 DataNodeStoragelnfo 类 中 ， 最 终 映射 到 块 的 链表 操作 方法 是 listInsert 和 listRemove。 此 外 在 BlockinfoContiguous 类 中 ， 还 有 一 个 moveBlockToHead 操 作 ， 此 操作 的 作用 
下 面 主 要 分 析 一 下 这 3 个 方法 。 


1.listinsert 


listinsert 的 操作 效果 是 往 对 应 节点 链表 中 添加 一 个 块 ， 触 发 此 操作 的 原始 方法 为 DataNodeStoragelnfo 的 addBlock 方 法 ， 如 下 : 


是 将 块 移 到 链表 头 部 。 





public AddBlockResult addBlock (BlockInfoCcontiguous b) { 
// 首先 检查 此 块 是 否 属于 同 个 DataNode 上 不 同 的 存储 位 置 


AddBlockResult result = AddBlockResult .ADDED; 
DatanodeStorageInfo otherStorage = 
b.findStorageInfo (getDatanodeDescriptor ()); 


if (otherStorage != null) { 

if (otherStorage != this) { 

// 如 果 的 确 属于 不 同 的 存储 位 置 ， 则 在 之 前 的 位 置信 息 中 将 当前 块 移 除 
otherStorage.removeBlock (b); 
result = AddBlockResult .REPLACED; 

} else { 
// 如 果 位 置信 息 一 致 ， 则 返回 已 经 存在 的 状态 结果 
return RddBlockResult.ALREADY EXIST; 

BE 


// 为 块 添加 当前 的 存储 位 置信 息 

b.addstorage (this); 

/将 当 前 亿 基 入 链 朋 

blockList = b.listInsert (blockList, this); 

















numBlocks++; 


return result; } 








在 这 个 方法 中 ， 主 要 关注 末尾 的 两 个 操作 : b.addStorage 和 |b.listinsert。b.addStorage 的 意思 是 在 新 增 的 块 中 赋值 当前 的 节点 信息 ， 因 


链表 信息 中 。 





为 此 块 是 被 写 入 当前 节点 中 的 ， 要 把 节点 信息 写 入 块 自身 维护 的 








// 为 块 增加 一 个 存储 位 置信 息 

boolean addstorage (DatanodeStorageInfo storage) { 
// triplets 数 组 扩容 1 个 单位 的 节点 位 置 ， 相 当 于 扩充 3 个 对 象 
int lastNode = ensureCapacity(1); 
// 设置 节点 位 置信 息 对 象 到 triplets[3 * lastNode] 中 
setStorageInfo (lastNode, storage); 
// 设置 下 一 个 块 为 nu11 到 triplets[3 * lastNode + 2] 
setNext (lastNode, null); 
// 设置 前 一 个 块 为 nu11 到 triplets[3 * lastNode + 1] 
setPrevious (lastNode, null); 
return true; 





} 

Private void setStorageInfo (int index, DatanodeStorageInfo storage) { 
assert this.triplets != null : "BlockInfo is not initialized"; 
assert index >= 0 && index*3 < triplets.length : 
triplets[index*3] = storage; 

} 


Private BlockInfoContiguous setPrevious (int index, BlockIinfoContiguous to) 
assert this.triplets != null : "BlockInfo is not initialized"; 
assert index >= 0 && index*3+1 < triplets.length : 
BlockInfoContiguous info = (BlockInfoContiguous)triplets[index*3+1]; 
triplets[index*3+1] = to; 
return info; 


"Index is out of bound"; 


t 


"Index is out of bound'" 7 





另外 一 个 操作 是 把 此 块 的 信息 加 入 到 当前 维护 的 链表 中 ， 将 head 头 节点 blocklist 以 参数 的 形式 传 入 ， 然 后 将 返回 值 重 新 赋值 给 头 节点 ， 相 当 于 进行 了 一 次 头 节点 的 更 新 。 








// 此 处 返回 的 blockList 为 新 的 头 节点 
blockList = b.1ListInsert (blockList, this); 














listinsert 方 法 具体 操作 如 下 : 





BlockInfoContiguous listInsert (BlockInfoContiguous head, 
DatanodeStorageInfo storage) { 
// 在 当前 块 中 寻找 对 应 节点 位 置 的 下 标 
int dnIndex = this. dStorageInfo (storage) 7 
assert dnIndex >= 0 : "Data node is not found: current"7 
assert getPrevious (dnIndex) == null && getNext (dnIndex) 一 null : 
"Block is already in the list and cannot be inserted."; 
this .setPrevious (dnIndex, null); 
// 将 当前 的 下 一 节点 指向 头 节点 
this .setNext (dnIndex, head); 
if(head != null) 
// 将 头 节点 的 前 一 节点 指向 当前 节点 
head. setPrevious (head. findStorageInfo (storage), this); 
// 返回 当前 节点 为 新 的 头 节点 


return this; 

















在 之 前 addStorage 方 法 中 设置 的 null 会 在 此 操作 中 连 向 head 头 节点 。 此 部 分 过 程 见 


2.listRemove 


另外 一 个 对 应 的 操作 是 节点 的 removeBlock 动 作 。 在 节点 上 执行 了 删除 块 动作 之 后 ， 
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图 6-8。 


会 触发 以 下 链表 操作 : 


图 6-8 块 添加 操作 流程 







BlocklnfoContiguous Head 











previousBlock nextBlock 





public boolean removeBlock (BlockIinfoContiguous b) { 
blockList = b.listRemove (blockList, this); 
if (b.removeStorage (this)) { 
numBlocks-——; 
return true; 
} else { 
return false; 
} 
} 








同样 会 有 两 个 步骤 ， 第 一 从 链表 中 移 除 掉 目 标 块 ， 第 二 从 目标 块 自身 中 释放 掉 关 于 其 存储 节点 的 信息 。 首 先 来 看 listRemove 将 当前 目标 块 清除 的 操作 : 


BlockInfoContiguous listRemove (BlockInfoContiguous head, 

DatanodeStorageInfo storage) { 

if (head == null) 
return null; 

int dnIindex = this 

// 此 块 不 存在 于 当前 的 

if(dnIndqex < 0) 
return head; 


// 将 对 应 的 当前 节点 信息 置 为 空 

BlockInfoContiguous next this.getNext (dnIndex); 
BlockInfoContiguous prev = this.getPrevious (dnIindex); 
this .setNext (dnIndex, null); 

this .setPrevious (dnIndex, null); 


// 将 前 后 节点 关联 





indStorageInfo (storage); 


列表 中 








if(prev != null) 
prev.setNext (prev.findStorageInfo (storage), next); 
if(next != null) 


next .setPrevious (next.findStorageInfo (storage), prev); 
// 如 果 当 前 为 头 节点 ， 则 蔡 换 头 
if(this == head) 

head = next; 
return head; 








还 有 一 个 操作 是 将 目标 块 中 的 相关 节点 信息 设置 为 空 : 





// 移 除 块 的 存储 位 置信 息 
boolean removeStorage (DatanodeStorageInfo storage) { 
int dnIndt = findStorageInfo (storage); 
// 如 果 节 点 没有 找到 ， 则 直接 返回 
if(dnIndex < 0) 
return false; 
assert getPrevious (dnIndex) 一 null && getNext (dnIndex) 一 null : 
"Block is still in the list and must be removed first."7 
// 寻找 最 后 一 个 不 为 空 的 节 
int lastNode = numNodes () 
// 用 最 后 一 个 节点 取代 当前 节点 
setStorageInfo (dnIndex, getStorageInfo (lastNode) ) 7 
SetNext (dnIndex, getNext (lastNode)); 
setPrevious (dnIndex, getPrevious (lastNode)); 
// 置 空前 后 连接 的 块 信息 以 及 DataStorageInfo 信 息 
setStorageInfo (lastNode, null); 
setNext (lastNode, null); 
setPrevious (lastNode, null); 
return true; 










































这 里 的 动作 是 将 最 后 一 个 节点 的 位 置 蔡 换 到 当前 要 删除 的 位 置 ， 并 将 原 最 后 节点 置 为 空 。 这 是 为 了 方便 后 面 在 ensureCapacity 方 法 中 动态 扩充 triplets 数 组 的 大 小 时 ， 无 需 


3.moveBlockToHead 


moveBlockToHead 操 作 也 是 BlocklnfoContiguous 类 中 经 常会 被 调用 的 方法 ， 此 方法 会 在 HDFS 块 上 报 处 理 的 过 程 方法 reportDiff 中 被 调 有 


private void reportDiff (DatanodeStorageInfo storageInfo, 
BlockListAsLongs newReport, 
Collection<BlockInfoContiguous> toAdd, 
Collection<Block> toRemove, 
Collection<Block> toInvalidate, 
Collection<BlockToMarkCorrupt> toCorrupt, 
Collection<StatefulBlockInfo> toUC) { 


// 新 建 一 个 delimiter 分 隔 块 ， 用 于 分 离 汇报 上 来 的 块 以 及 那些 没有 被 汇报 上 来 的 块 
BlockInfoContiguous delimiter = new BlockInfoContiguous (new Block(), (short) 1); 
AddBlockResult result = storageInfo.addBlock (delimiter); 
assert result == AddBlockResult .ADDED 

"Delimiting block cannot be present in the node"; 
int headIindex = 0; //currently the delimiter is in the head of the list 
int curIndex; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 对 汇报 上 来 的 块 进行 处 理 
for (BlockReportReplica iblk : newReport) { 
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// 移动 块 到 链表 头 部 
if (storedBlock != null && 
(curIndex = storedBlock.findStorageInfo (storageInfo)) >= 0) { 
headIndex = storageInfo.moveBlockToHead (storedBlock, curIindex, headIndex); 
} 
} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 























所 创建 对 象 数组 。 











原理 是 通过 将 块 移动 到 标记 块 的 一 人 出， 用 以 区 分 哪些 块 在 本 轮 被 汇报 过 ，moveBlock-ToHead 的 作用 是 将 块 直接 移 到 链表 头 部 : 














// 移动 块 到 链表 头 部 
public BlockIinfoContiguous moveBlockToHead (BlockInfoContiguous head, 
DatanodeStorageInfo storage, int curIndex，int headIndex) { 
if (head == this) { 
return this; 


‘ 

// 将 当前 块 的 下 一 节点 指向 头 节点 

BlockInfoContiguous next = this.setNext (curIndex, head); 

// 置 空前 一 节点 

BlockInfoContiguous prev = this.setPrevious (curIndex, null); 


// 设置 头 节点 的 前 一 空 
head. setPrevious (headIndex, this); 
// 将 当前 节点 原来 的 前 后 节点 相连 
prev.setNext (prev.findStorageInfo (storage), next); 
if (next != null) { 
next .setPrevious (next.findStorageInfo (storage), prev); 
} 


return this; 











此 部 分 流程 见 图 6-9。 





























在 BlocklnfoContiguous 类 中 ， 还 有 一 些 其 他 辅助 方法 ， 这 里 主要 分 析 其 中 的 3 种 方法 ， 也 是 经 常 被 调用 的 3 种 方法 。 图 6-10 所 示 的 是 BlocklnfoContiguous 中 所 有 的 操作 方法 。 
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图 6-9 moveBlockToHead 流 程 图 
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图 6-10 BlockInfoContiguous 内 部 的 操作 方法 


6.3.3” 块 迭 代 器 Blocklterator 














对 于 一 个 节点 ， 我 们 想 要 遍历 上 面 的 块 ， 就 需要 一 个 迭代 器 ， 能 够 通过 类 似 next 的 方法 获取 其 中 的 块 。 在 JDK 自 带 的 链表 中 是 有 直接 获取 的 方法 的 ， 但 是 对 于 HDF 为 块 设计 的 这 套 特 殊 链表 中 ， 我 们 需 
要 自己 额外 构造 相应 的 迭代 器 。HDFS 的 内 部 也 的 确 设计 了 这 样 的 迭代 器 ， 下 面 是 总 迭代 器 类 ， 代 码 如 下 : 












































// DataNode 内 部 的 总 和 途 代 器 ， 包 含 了 每 个 存储 目录 下 的 从 代 器 对 象 

private static class BlockIterator implements Iterator<BlockInfoContiguous> { 
private int index = 0; 
//_DataNode 存 储 目 录 对 应 的 迭代 器 列表 


private final List<Iterator<BlockInfoContiguous>> iterators; 


private BlockIterator (final DatanodeStorageInfohttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... storages) { 
List<Iterator<BlockInfoContiguous>> iterators = new ArrayList<Iterator<BlockInfoContiguous>>(); 
for (DatanodeStorageInfo e : storages) { 
iterators.add (e.getBlockIterator () ) 7 
} 
this.iterators = Collections.unmodifiableList (iterators); 
} 


// 判断 是 否 还 有 下 一 个 块 
public boolean hasNext() { 

update ()，; 

return !iterators.isEmpty() && iterators.get (index) .hasNext (); 
} 


// 获取 下 一 个 块 方法 

public BlockInfoContiguous next() { 
Update (); 
return iterators.get (index) .next (); 


} 
// 暂 不 支持 移 除 方法 


Public void remove () { 
throw new UnsupportedOperationException ("Remove unsupported."); 


} 


// 更 新 跳 过 一 个 块 
private void update() { 
while (index < iterators.size() - 1 && !iterators.get (index) .hasNext ()) { 
indext++; 
i 
} 


Storages 节 点 信息 是 以 参数 的 形式 传 入 的 : 


DatanodeStorageInfo[] getStorageInfos () { 
synchronized (storageMap) { 
final Collection<DatanodeStorageInfo> storages = storageMap.values (); 
return storages.toArray (new DatanodeStorageInfo[storages.size()]); 
} 
i 








具体 迭代 器 的 内 部 设计 如 下 : 





// DataNode 内 部 针对 每 个 存储 目录 的 块 遍 历 迭 代 器 
Class BlockIterator implements Iterator<BlockInfoContiguous> { 
private BlockInfoContiguous current; 


BlockIterator (BlockIinfoContiguous head) { 
this.current = head; 


} 


public boolean hasNext() { 
return current != null; 


} 


public BlockInfoContiguous next() { 
BlockInfoContiguous res = current; 
current = current .getNext (current.findStorageInfo (DatanodeStorageInfo.this)); 
return res; 


} 


public void remove() { 
throw new UnsupportedOperationException ("Sorry. can't remove."); 
} 
} 











在 DecommisionManager 的 processForDecominternal 方 法 中 就 用 到 了 这 个 迭代 器 : 











private AbstractList<BlockInfoContiguous> handleInsufficientlyReplicated!( 
final DatanodeDescriptor datanode) { 
AbstractList<BlockInfoContiguous> insufficient = new ChunkedArrayList<>(); 
// 调用 DataNode 和 迭代 器 进行 下 线 节 点 中 块 的 遍历 
processBlocksForDecomInternal (datanode, datanode.getBlockIterator(), 
insufficient, false); 
return insufficient; 




















以 上 内 容 就 是 本 节 主 要 讲述 的 关于 HDFS 块 链表 方面 的 内 容 ， 也 帮 大 家 复习 了 数据 结构 中 的 常见 链表 操作 。 这 里 需要 提醒 一 点 ， 一 旦 集群 中 的 块 数 达到 和 干 万 级 别 ，BlokclnfoContiguous 对 象 同样 会 消耗 
掉 大 量 的 存储 空间 ， 也 就 是 说 同时 会 有 干 万 个 INodeFile 和 BlocklnfoContiguous 对 象 在 NameNode 的 内 存 中 。 




















6.4 小 结 


























本 章 的 内 容 并 不 算 太 多 ， 大 体 上 大 家 做 到 理解 、 会 用 即 可 ， 尤 其 像 镜像 文件 相关 的 处 理 命令 hdfs oiv， 有 时 候 会 帮 有 我 们 不 少 忙 。BlocklnfoContiguous 类 的 设计 与 其 对 于 块 的 组 织 是 本 章 的 一 个 难点 ， 


还 需 读者 反复 阅读 、 理 解 。 





三 部 分 解决 方案 篇 


第 7 章 HDFS 的 数据 管理 









































在 本 章 中 ， 我 们 将 会 学 习 到 在 真实 应 用 环境 中 的 一 些 实践 经 验 。 比 如 说 对 HDFS 正 常 读 写 的 限 流 方案 ， 又 比如 说 HDFS 的 数据 规模 的 监控 ， 以 此 帮助 我 们 了 解 目前 集群 的 一 个 数据 统计 情况 。 还 有 关于 
HDFS 上 的 数据 以 及 DataNode 迁 移 的 方案 。 最 后 是 笔者 在 实践 过 程 中 做 过 的 稍微 简单 一 些 的 操作 ， 比 如 HDFS 的 重 命名 方案 以 及 配置 化 管理 操作 。 
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在 本 章 中 ， 我 们 将 会 学 习 到 在 真实 应 用 环境 中 的 一 些 实践 经 验 。 比 如 说 对 HDFS 正 常 读 写 的 限 流 方案 ， 又 比如 说 HDFS 的 数据 规模 的 监控 ， 以 此 帮助 我 们 了 解 目前 集群 的 一 个 数据 统计 情况 。 还 有 关于 
HDFS 上 的 数据 以 及 DataNode 迁 移 的 方案 。 最 后 是 笔者 在 实践 过 程 中 做 过 的 稍微 简单 一 些 的 操作 ， 比 如 HDFS 的 重 命名 方案 以 及 配置 化 管理 操作 。 




















7.1 ”HDFS 的 读 写 限 流 方 案 








HDFS 的 读 写 限 流 指 的 是 在 HDFS 普 通读 写 文件 块 的 操作 中 ， 对 其 速率 进行 限制 ， 防 止 出 现 网 络 带宽 打 满 的 现象 。 在 之 前 第 5.1 节 中 ， 我 们 讲述 过 HDFS 内 部 的 一 些 限 流 场景 ， 但 是 对 于 普通 的 读 写 操 
作 ，HDFS 并 没有 做 限 流 。 本 节 所 讲述 的 限 流 方案 正 是 基于 这 个 前 提 。 本 节 将 详细 地 介绍 此 次 的 限 流 方案 ， 包 括 它 的 设计 、 实 现 以 及 最 后 的 测试 结果 分 析 。 








7.1.1 ” 限 流 方案 实现 要 点 以 及 可 能 造成 的 影响 

















本 节 的 使 用 场景 为 : 集群 大 任务 运行 时 ， 打 满 网 络 带 宽 ， 导 致 影响 到 其 他 业务 方 服务 的 运行 。 


























以 下 列 出 的 内 容 是 限 流 方案 实现 中 需要 考虑 的 一 些 因素 ， 以 及 这 些 因素 在 实现 过 程 中 可 能 对 现 有 系统 产生 的 影响 。 











“ 限 流 的 操作 对 象 应 该 是 远程 读 和 普通 写 操作 ， 而 不 应 该 包括 本 地 读 的 操作 。 在 HDFS 中 ， 任 何 读 写 操作 都 会 尽 可 能 地 选择 本 地 的 方式 进行 读 写 ， 这 样 可 以 避免 网 络 数 据 传输 ， 所 以 本 地 读 在 读 操作 中 占 
的 比例 还 是 很 高 的 。 在 这 一 点 上 ， 需 要 进行 过 滤 ， 否 则 很 容易 “误伤 ”， 导 致 无 效 的 带宽 限制 。 而 普通 的 写 操 作 我 们 大 体 上 可 以 看 作 是 分 布 式 的 写 操作 ， 直 接 限 流 就 可 以 了 。 

“ 需要 新 增 动态 调整 限 流 带 宽 的 管理 命令 。 操 作 命令 应 该 类 似 于 设置 带宽 的 命令 dfsadmin-setBandwidth。 因 为 有 的 时 候 ， 我 们 对 集群 进行 限 流 只 是 在 特定 的 期 间或 特定 的 时 段 ， 其 余 正 常 的 时 段 需 要 能 够 
关闭 限 流 功 能 。 所 以 这 里 需要 有 动态 的 调整 手段 ， 而 不 是 每 次 需要 重启 DataNode 进 程 服务 。 

"IPC 通信 的 超时 时 间 需 要 增 大 。 这 一 点 是 之 前 在 HDFS 内 部 限 流 章节 中 没有 提 到 的 一 点 ， 这 点 也 是 笔者 在 真实 测试 使 用 时 发 现 的 一 个 问题 。 当 限 流 功能 打开 的 时 候 ， 因 为 一 个 写 操作 是 以 Pipeline 的 形式 
写 到 3 个 节点 中 的 ， 所 以 限 流 操作 会 导致 拖 慢 当前 节点 ， 进 而 拖 慢 此 节点 的 下 游 节点 。 所 以 有 的 时 候 会 引起 IPC 通 信 的 超时 ， 会 出 现 Socket Timeout 的 现象 。 而 且 如 果 有 很 多 个 文件 读 写 交 慢 ， 也 会 使 集群 整体 
的 吞吐 量 下 降 。 


7.1.2 ” 限 流 方案 实现 


对 于 限 流 方案 的 实现 ， 本 节 不 会 讲述 具体 代码 实现 的 细节 ， 在 本 节 未 尾 ， 会 给 出 一 份 patch 文 件 的 链接 。 这 个 patch 的 原型 是 Hadoop 社 区 上 的 JIRA: HDFS-9796 (Add throttler for datanode 
bandwidth) 。 基 于 这 个 最 初 的 原型 ， 我 们 加 入 了 自身 的 额外 需求 (patch 可 能 不 能 直接 应 用 到 别 的 版 本 的 HDFS 源 码 中 ， 但 是 读者 可 以 阅读 patch 代 码 做 对 照 更 改 ) 。 下 面 主要 分 析 其 中 的 细节 原理 以 及 实 
现 逻 辑 : 


















































“ DataXceiver 的 readBlock、writeBlock 的 限 流 。 之 前 已 经 提 到 过 ， 在 HDFS 中 做 普通 读 写 的 限 流 其 实 非常 简单 ， 只 要 在 所 有 读 写 操作 方法 的 前 一 步 ， 传 入 一 个 限 流 器 对 象 即 可 。 这 个 限 流 器 对 象 与 Balancer 
数据 限 流 器 是 同一 个 实现 类 。 读 操作 经 过 的 是 readBlock 方 法 ， 而 写 操 作 则 是 writeBlock， 所 以 我 们 要 新 建 一 个 DataThrottler 的 限 流 器 对 象 ， 以 参数 的 形式 传 入 这 2 个 方法 。 同 时 在 readBlock 的 时 候 ， 一 定 要 判定 
是 否 为 本 地 读 的 情况 ， 如 果 是 则 传 入 null， 代 表 不 限 流 。 判 断 的 核心 是 下 面 这 行 代码 ， 通 过 Socket 连 接 对 象 类 型 来 做 判断 : 


DataTransferThrottler dataThrottler = 
Peer.isLocal () ? null : dataXceiverServer.dataThrottler; 





“ 新 增 动态 设置 限 流 带 宽 速 率 的 命令 。 动 态 设置 限 流 带 宽 命 令 的 目的 在 上 文中 已 经 提 到 过 了 ， 还 是 非常 有 必要 的 ， 实 现 的 原理 几乎 与 dfsadmin 带 宽 设 置 命令 一 致 。 通 过 dfsadmin 带 宽 设 置 命令 将 目标 带宽 


值 发 送 给 NameNode， 然 后 NameNode 通 过 心跳 的 方式 将 新 的 带宽 值 发 送 到 各 个 DataNode 上 并 进行 更 新 。 但 是 这 种 方式 唯一 的 缺点 是 它 是 统一 设置 的 命令 ， 不 会 有 差异 性 。 在 Hadoop 中 要 想 新 增 使 用 命令 ， 需 
要 添加 新 的 RPC 接 口 ， 而 且 需 要 更 改 pb 协议 。 


7.1.3 ” 限 流 测试 结果 


这 个 patch 完 成 之 后 ， 笔 者 把 它 打 入 到 了 我 们 内 部 的 Hadoop 版 本 中 ， 并 重新 进行 了 编译 、 打 包 、 发 布 。 随 后 我 们 发 现 了 一 些 有 意思 的 现象 。 














当 我 们 只 对 其 中 的 1 台 节 点 打开 限 流 操作 后 ， 其 影响 很 小 ， 我 们 用 hadoop fs-put 大 文件 的 方式 进行 测试 ， 一 切 正常 。 而 当 我 们 对 集群 中 所 有 的 hdfs 的 jar 包 进行 更 新 并 全 部 限 流 到 10MB 时 ， 试 验 结果 还 
是 很 明显 的 ， 上 传 大 文件 的 时 间 从 之 前 的 耗 时 几 秒 到 测试 时 的 几 分 钟 。 

















后 来 我 们 在 线 上 集群 测试 的 结果 能 够 显示 出 在 中 小 规模 集群 中 对 HDFS 进 行 限 流 还 是 能 够 起 到 一 定 作用 的 。 但 是 注意 这 里 有 一 个 前 提 : 中 小 规模 集群 。 如 果 是 集群 节点 数 过 万 的 大 规模 集群 ， 可 能 会 遇 到 
如 上 文中 提 到 的 拖 慢 整个 集群 的 问题 。 所 以 在 这 一 点 上 ， 社 区 也 没有 将 HDFS-9796 合 入 到 主干 代码 ， 原 因 也 大 致 在 于 此 。 对 于 HDFS 的 内 部 限 流 ， 仍 然 需要 更 好 的 、 考 虑 更 周全 的 限 流 方案 。 最 后 给 出 笔者 
基于 HDFS-9796 改 造 后 的 代码 Patch 链接: https://github.com/linyiqun/open-source-patch/blob/master/hdfs/others/HDFS-dataThrottler/HDFS-dataThrottler.patch。 


























Shuffle 限 流 























笔者 使 用 上 述 方式 在 HDFS 中 进行 限 流 ， 有 的 时 候 还 是 会 出 现 个 别 时 间 点 带宽 靓 升 的 场景 ， 后 来 发 现 可 能 是 Reduce 任 务 shuffle 数 据 导致 的 。 因 为 shuffle 的 数据 是 Map 任 务 产 生 的 中 间 结 果 数 据 ， 中 间 
结果 数据 是 不 走 HDFS 过 程 的 ， 所 以 HDFS 的 限 流 对 它 其 实 不 起 作用 。 当 然 ， 如 果 你 想 对 shuffle 过 程 做 限 流 ，HDFS 这 套 限 流 逻辑 也 完全 适用 。 但 是 这 并 不 能 确保 完全 限制 流量 ， 可 能 在 未 来 某 个 时 刻 又 会 有 
未 预料 到 的 因素 出 现 。 所 以 最 好 的 办 法 还 是 在 Hadoop 系 统 外 部 来 做 ， 比 如 对 集群 所 在 的 机 房 做 总 带宽 限制 。 















































7.2“HDFS 数 据 资源 使 用 量 分 析 以 及 趋势 预测 


我 们 可 以 预测 出 其 中 的 变化 趋势 ， 然 后 做 针对 性 地 集群 扩容 等 工作 。 本 节 将 为 大 家 介绍 获取 HDFS 资 源 使 F 
第 一 ， 要 获取 的 指标 数据 ; 第 二 ， 获 取 数 据 的 方法 ; 第 三 ， 数 据 的 使 用 。 









































HDFS 资 源 使 用 量 是 集群 监控 统计 中 一 项 十 分 重要 的 指标 数据 。 通 过 此 数据 ， 我 们 不 仅 可 以 了 解 集群 每 日 新 增 的 文件 、 目 录 数 ， 还 能 知道 集群 每 天 写 出 了 多 少量 的 数据 。 通 过 不 断 采 集资 源 使 用 量 数据 ， 
























































7.2.1 要 获取 哪些 数据 














量 数 据 的 方法 ， 有 了 这 些 数据 后 ， 我 们 才能 做 后 面 的 趋势 预测 。 本 节 大 致 划分 成 3 个 部 分 来 讲述 : 








数据 不 是 获取 得 越 多 、 越 细 就 越 好 ， 因 为 我 们 还 要 考虑 其 中 的 成 本 代价 。 在 这 里 我 们 很 明确 ， 我 们 只 需要 一 个 宏观 上 的 数据 ， 总 体 使 用 情况 的 一 些 数据 ， 比 如 dfs 资 源 使 用 量 等 这 类 的 数据 信息 。 这 些 信 
息 可 以 参考 NameNode 上 的 页 面 数据 ， 图 7-1 所 示 即 为 可 选 的 一 些 数据 。 




















Summary 


Security is off 


Safemode is off. 


714 files and directorie®, 2049 blocks € 12763 total filesystem object(S). 
Heap Memory used 396.22 MBo B Heap Memory Max Heap Memory is 889 MB. 


Non Heap Memory used 43.27 MB of 43.81 MB Commited Non Heap Memory. Max Non Heap Memory is 130 MB. 











Configured Capacity: 393.22 GB 


DFS Used: 128.75 MB (0.03%) 


Non DFS Used: 40.07 GB 


DFS Remaining: 353.03 GB (89.7839) 


Block Pool Used: 128.75 MB (0.03%) 


DataNodes usages% (Min/Median/Max/stdDev): 0.01% /0.01% /0.10% / 0.04®® 


Live Nodes 4 (Decommissioned: 0) 


Dead Nodes 1 (Decommissioned: 0) 


Decommissioning Nodes 
Total Datanode Volume Failures 


Number of Under-Renlicated Blocks 


图 7-1 NameNode 数 据 使 用 情况 指标 



































这 些 数 据 足 以 用 来 展示 目前 集群 的 数据 使 用 情况 以 及 进行 数据 的 未 来 分 析 。 我 们 可 以 以 这 些 数 据 为 目标 ， 想 办 法 去 获取 这 些 数 据 。 





7.2.2 ”如 何 获 取 这 些 数 据 
































目标 倒是 有 了 ， 但 是 如 何 去 获 取 这 些 数据 呢 》 如 果 你 想 用 hdfs 命 令 行 的 方式 去 获取 ， 答 案 当 然 是 可 以 的 ， 研 究 过 hadoop-2.7.1 源 码 的 同学 们 应 该 知道 ， 这 个 版 本 的 发 布 包 里 包含 了 许多 分 析 镜 像 文件 的 
命令 ， 这 些 命令 可 以 离线 计算 出 集群 中 文件 块 的 信息 ， 这 些 命令 具体 都 是 以 hdfs oiv 开 头 ，oiv 就 是 OfflinelmageView 的 缩写 。 但 是 这 种 方法 有 几 个 头 端 : 效率 低 ， 性 能 差 。 为 什么 这 么 说 呢 ， 因 为 分 析 镜 


























像 文件 数据 的 时 候 ， 数 据 每 次 都 需要 重新 计算 ， 而 且 当 镜 像 文件 变 得 越 来 越 大 的 时 候 ， 所 需要 的 计算 耗 时 也 会 随 之 增 大 。 而 且 这 个 命令 本 身 属 于 离线 分 析 型 的 命令 ， 不 适合 定时 周期 性 地 运行 。 假 设 我 们 想 
缩小 数据 获取 间隔 ，30 分 钟 获取 一 下 文件 块 数量 ， 人 怎么 办 ?所 以 最 佳 的 办 法 还 是 以 NameNode 页 面 数据 获取 的 方式 去 拿 到 这 些 数 据 。 因 为 我 们 经 常 刷新 页 面 就 能 得 到 更 新 过 后 的 数据 ， 说 明 NameNode 页 
面 有 自己 的 一 套 获 取 此 方面 数据 的 方法 ， 只 要 我 们 找到 了 这 方面 的 代码 ， 基 本 就 算 大 功 告 成 了 。 这 里 我 们 省 略 如 何 找到 这 部 分 代码 的 过 程 ， 直 接 给 出 结果 。HDFs 的 确 没有 在 dfsadmin 这 样 的 命令 中 添加 类 


似 数据 获取 的 命令 ， 也 没有 添加 对 应 的 RPC 接 口 。 笔 者 最 后 是 通过 控制 此 页 面 的 dfshealth.html 文 件 才 找到 这 段 代码 的 ， 最 终 使 






















































































// 此 类 用 于 获取 集群 页 面 上 所 展示 的 数据 
QInterfaceAudience.Private 
class ClusterJspHelper { 
private static final Log LOG = LogFactory.getLog (ClusterJspHelper.class); 
public static final String OVERALL STATUS = "overall-status"; 
public static final String DEAD = "Dead"; 
private static final String JMX QRY = 
"/jmx?qry=Hadoop: service=NameNode, name=NameNodeInfo"; 


// 获取 集群 健康 报告 


ClusterStatus generateClusterHealthReport() { 
} 
// 获取 下 线 节点 报告 信息 


DecommissionStatus generateDecommissioningReport() { 


pb 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 集群 统计 信息 类 

static class ClusterStatus { 
/** Exception indicates failure to get cluster status */ 
Exception error = null; 


// 集群 状态 统计 信息 
// 集群 id 


String clusterid = ""; 
// 集群 总 容量 大 小 

lon: 
// 案 
long free sum = 0 


// 集群 已 便 用 空间 大 小 




















的 是 http 请 求 来 获取 信息 ， 相 关 类 代码 如 下 : 


long clusterDfsUsed = 0; 
// 集群 非 Gfs 数 据 使 用 的 大 小 
long nonDfsUsed sum = 0; 


// 集群 总 文件 目录 总 数 


long totalFilesAndDirectories = 0; 


// 集群 内 所 有 NameNode 信 息 


final List<NamenodeStatus> nnList = new ArrayList<NamenodeStatus>(); 


// NameNode 异 常 信息 图 


final Map<String，Exception> nnExceptions = new HashMap<string, Exception>(); 


汶 


2 
st 


NameNode 统 计 信 息 类 
atic class NamenodeStatus { 


人 


当然 不 是 所 有 的 方法 我 们 都 需要 ， 











我 们 只 


.FY 











获取 集群 健康 状况 报告 的 方法 : 





// 集群 健康 报告 生成 


ClusterStatus generateClusterHealthReport () { 


// 


ClusterStatus cs = new ClusterStatus(); 


初始 化 ClusterStatus 对 象 


Configuration conf = new Configuration(); 
List<ConfiguredNNAddress> nns = null; 


tx 


} 


#7 
fo. 


} 


nns = DFSUtil.flattenAddressMap ( 


DFSUtil .getNNServiceRpcAddresses (conf)); 


catch (Exception e) { 


// Could not build cluster status 


cs.setError (e); 
return cs; 


遍历 处 理 集群 中 的 每 个 NameNode 
r (ConfiguredNNAddress cnn : 


nns) { 


InetSocketAddress isa = cnn.getAddress (); 


NamenodeMxBeanHelper nnHelper = null; 


try { 


nnHelper = new NamenodeMXBeanHelper (isa, conf); 


// 获取 状态 信息 值 


String mbeanProps= queryMbean (nnHelper.httpAddress, conf); 


// 解析 状态 信息 值 到 NamenodeStatus 对 象 中 


NamenodeStatus nn = nnHelper.getNamenodeStatus (mbeanProps); 


if (cs.clusterid.isEmpty() || cs.clusterid.equals ("") ) 


cs.clusterid = nnHelper.getClusterId (mbeanProps); 


} 
cs.addNamenodeStatus (nn); 
catch ( Exception e ) { 


{ // Set clusterid only once 


// track exceptions encountered when connecting to namenodes 
cs.addException (isa.getHostName (), e); 


continue; 


} 


return cs; 


bE: 





在 NamenodeStatus 这 个 类 中 就 包含 了 我 们 想 要 的 监控 数据 信息 : 





// 此 类 保存 了 集群 内 部 基本 的 数据 统计 信息 


Stat 
// 


String host = 
// NameNode 总 容量 


long 


ic class NamenodeStatus { 
主机 名 





capacity = 0L7 


// 可 用 空间 大 小 


long 


free = 0L; 


// 目前 空间 使 用 量 


long 


bpUsed = 0L; 


// 非 HDFS 使 用 量 


long 


nonDfsUsed = 0L; 


// 文件 目录 总 数 


lon: 


filesAndDirectories = 0L; 


// 块 总 数 


long blocksCount = 


OL; 


// 丢失 的 块 总 数 


long 


missingBlocksCount = 0L; 


// 目前 活跃 的 DataNogde 数 量 


int 


liveDatanodeCount = 0; 


// 正在 下 线 节点 的 数量 


int 


// 已 经 处 于 dead 状 态 的 节点 数 


int deadDatanodeCount 





liveDecomCount = 0 








// 已 经 下 线 完毕 的 节点 数 
int deadDecomCount = 0; 
// http 地 址 

URL httpAddress = null; 
// 软件 版 本 信息 


String softwareVersion = ""; 


i 


思路 大 致 清楚 ， 下 面 就 是 把 这 段 程序 搬出 来 ， 套 入 到 自己 的 java 程 序 中 即 可 ， 样 例 程 序 会 在 本 节 末尾 给 出 。 
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现在 来 考虑 一 个 实际 的 问题 : 有 了 这 些 数据 我 们 怎么 








把 么 用 这 些 数 据 
































。 首 先 要 明 


























增长 走势 ， 所 以 建议 做 成 折线 趋势 图 ， 可 以 分 为 两 个 维度 : 
1) 文件 目录 数 、 块 数 折线 趋势 图 。 因 为 这 两 个 指标 可 以 


群 的 性 能 造 




















影响 。NameNode 因 














会 维护 大 量 的 块 对 象 数据 。 而 | 














于 发 现 集群 每 日 的 写 入 量 多 少 。 
信息 压力 会 很 大 。 第 二 个 指标 块 数 的 统计 在 一 定 程度 上 能 反映 出 小 文件 的 数量 情况 ， 
群 ， 那 这 些 不 到 1MB 的 文件 必然 是 单独 的 1 个 块 (一 般 我 们 不 会 把 块 大 小 设置 成 小 于 1MB) ， 然 后 会 造成 块 增长 趋势 与 文件 、 
上 且 Hadoop 本 身 不 适用 于 小 文件 的 存储 ， 因 














一 件 事情 ， 数 据 拿 来 是 要 存 下 来 的 。 所 以 首先 就 是 存 入 数据 库 中 ， 间 隔 周 期 可 以 自己 调 。 一 般 这 样 的 数据 比较 倾向 于 


一 旦 集群 所 持 有 的 文件 、 块 数 太 多 ， 会 导致 NameNode 内 存 吃 紧 。 因 为 NameNode 要 维护 如 此 庞大 的 元 数据 
因为 一 旦 小 文件 多 了 ， 会 对 集群 造成 十 分 严 








oy 
尿 / 














于 分 析 数 据 

















向 。 比 如 极端 一 点 的 情况 : 假设 我 们 把 很 多 不 到 1MB 的 文件 写 入 集 








录 的 数 











增长 趋势 类 似 。 即 便 存 储 空间 并 没有 受到 很 大 的 影响 ， 但 是 会 对 集 














为 每 读 一 个 文件 它 要 启动 


一 个 新 任务 ， 需 要 一 定 的 成 本 代价 。 一 旦 你 的 小 文件 过 多 ， 首 先 会 启 


动 大 量 的 Map 任 务 去 读 文 件 ，1 个 任务 一 般 读 1 个 文件 。 所 以 有 些 极端 情况 下 ， 某 个 Job 会 有 上 干 、 上 万 个 任务 在 运行 。 这 个 现象 笔者 在 工作 中 也 确实 经 历 过 。 


[D 








司 7- 








dfs 磁 盘 空间 使 



































量 的 趋势 分 析 图 。 这 个 很 好 理解 ， 

















2、7-3 是 针对 以 上 两 点 的 实际 效果 轿 











， 测 试 的 数据 来 





我 们 就 是 想 知道 集群 每 天 数据 增长 的 总 量 是 多 少 ， 方 便 未 来 在 适当 的 时 候 增加 机 器 来 扩充 集群 的 容量 。 





自 于 笔者 的 测试 集群 。 


每 天 HDFS 文 件 目录 趋势 图 


-全 ~ Block 块 数 -看 - 文件 目录 总 数 


图 7-2 文件 、 块 数量 趋势 


这 里 有 个 小 建议 ， 在 做 预测 分 析 图 表 的 时 候 ， 最 好 把 每 天 的 统计 数据 和 每 小 时 的 统计 数据 都 计算 一 遍 ， 一 是 能 方便 地 知道 集群 内 每 天 数据 的 增长 量 ， 





较 快 。 
下 面 是 获取 统计 数据 的 部 分 程序 ， 在 完整 代码 里 还 有 获取 NodeManager 信 息 的 程序 : 


每 天 dfs 资 源 使 用 量 


~@~ dfs 资 源 使 用 量 (T) 


和 
> 


0 
2015-11-05 2015-11-06 





























7-3 DFS 资源 使 用 趋势 

















二 是 我 们 能 够 了 解 到 一 天 内 哪些 时 段 数据 增长 得 比 


2015-11-08 





Public class Main 1{ 
public static void main (String[] args) { 
ClusterStatus cs; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 直接 调用 generateClusterHealthReport 方 法 获取 ClusterStatus 实 例 即 可 
cs = new ClusterJspHelper () .generateClusterHealthReport (); 
// 输出 获取 的 状态 信息 


printNameStatusInfo (cs, writedb); 


http: //wuw.hzcourse. Com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 输出 NameNode 内 的 统计 信息 
Private static void PrintNameStatusInfo (ClusterStatus cs, int writedb) { 

gdouble dfsUsedPercent; 

String[] values; 

List<NamenodeStatus> nsList; 

DbClient dbClient; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


nsList = cs.nnList; 

// 获取 到 NameNode 的 状态 信息 ， 并 逐一 输出 

for (NamenodeStatus ns : nsList) { 

values = new String[BaseValues.DB COLUMN CLUSTER STATUS LEN]; 

dfsUsedPercent = 1.0 * ns.bpUsed / ns. Capacity; 
// 输出 信息 内 容 含 义 可 见 上 文中 NamenodeStatus 类 中 的 注释 信息 
System.out .println ("host:" + ns.host); 
System.out.println ("blocksCount:" + ns.blocksCount); 
System.out .Print1ln 
System.out .Print1ln 
System.out .Println 


( 

("bpUsed:" + ns.bpUsed); 

("capacity:" + ns.capacity); 
("deadDatanodeCount:" + ns.deadDatanodeCount); 

System.out .println ("deadDecomCount:" + ns.deadDecomCount); 

System.out .println ("filesAndDirectories:" + ns.filesAndDirectories); 

System.out .Println("free:" + ns.free); 

System.out .println("liveDatanodeCount:" + ns.liveDatanodeCount); 
("liveDecomCount:" + ns.liveDecomCount); 
("missingBlocksCount:" + ns.missingBlocksCount); 
("nonDfsUsed:" + ns.nonDfsUsed); 
("dfsUsedPercent:" + dfsUsedPercent); 
("softwareVersion:" + ns.softwareVersion); 


System.out .println 
System.out .Print1ln 
System.out .Println 
System.out .Println 
System.out .Print1ln 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





最 后 附 上 完整 代码 的 链接 : 


https://github.com/linyiqun/yarn-jobhistory-crawler/tree/master/NMTool 


7.3 ”HDFS 关 姥 居 迁移 解决 方案 

















数据 迁移 指 的 是 一 种 大 规模 量 级 的 数据 转移 ， 转 移 的 过 程 中 往往 会 跨 机 房 、 跨 集群 。 数 据 迁 移 规模 的 不 同 会 导致 整个 数据 迁移 的 周期 也 不 尽 相同 。 本 节 我 们 要 讨论 的 主题 是 基于 HDFS 的 数据 迁移 。 在 
HDFS 中 ， 同 样 有 许多 需要 数据 迁移 的 场景 ， 比 如 冷 热 数据 集群 之 间 的 数据 转化 ， 或 者 HDFS 数 据 的 双 机 房 备份 等 等 。 因 为 涉及 跨 机 房 、 跨 集群 ， 所 以 数据 迁移 不 会 是 一 个 简单 的 操作 。 本 节 将 为 大 家 介绍 基 
于 DistCp 工 具 的 数据 迁移 方案 ， 首 先 将 会 列 出 数据 迁移 过 程 中 需要 考虑 的 各 个 因素 ， 随 后 介绍 DistCp 的 详细 使 用 ， 最 后 给 出 笔者 在 工作 中 的 一 次 操作 实例 。 


















































7.3.1 数据 迁移 使 用 场景 












































上 文中 提 到 的 冷 热 数据 的 同步 只 是 数据 迁移 的 一 个 使 用 场景 ， 那 么 数据 迁移 还 有 其 他 哪些 使 用 场景 呢 ， 这 里 总 结 出 了 如 下 几 个 : 











: 冷 热 集群 数据 分 类 存储 ， 详 见 上 文 描述 。 
“ 集群 数据 整体 搬迁 。 当 公司 的 业务 迅速 发 展 ， 导 致 当前 的 服务 器 数量 资源 出 现 临时 紧张 的 状况 ， 为 了 更 高 效 地 利用 资源 ， 打 算 将 原 A 机 房 数据 整体 迁移 到 B 机 房 ， 原 因 是 B 机 房 机 器 多 ， 而 且 B 机 房 本 身 


开销 较 A 机 房 开销 低 些 。 


* 数据 的 准 实时 同步 。 数 据 的 准 实时 同步 与 上 一 点 的 不 同 在 于 集群 数据 的 整体 搬迁 可 以 一 次 性 操作 解决 ， 而 准 实时 同步 则 需要 定期 同步 ， 而 且 要 做 到 周期 内 数据 基本 完全 一 致 。 数 据 准 实时 同步 的 目的 
在 于 数据 的 双 备 份 可 用 ， 比 如 某 天 A 集 群 突然 宣告 不 允许 再 使 用 了 ， 此 时 可 以 将 线 上 的 使 用 集群 直接 切 向 同步 集群 B。 因 为 B 集 群 实时 同步 A 集 群 数据 ， 拥 有 几乎 完全 一 致 的 真实 数据 和 元 数据 信息 ， 所 以 对 于 
业务 方 的 使 用 而 言 是 不 会 受到 任何 影响 的 。 


























在 上 述 3 个 使 用 场景 中 ， 第 一 个 相 比较 于 第 二 、 三 个 来 说 可 能 稍微 容易 一 些 ， 但 是 想 要 完全 做 好 也 不 简单 。 第 三 个 数据 的 实时 同步 相 比较 第 二 个 来 说 更 加 实际 一 些 。 因 为 如 果 公司 准备 做 集群 数据 迁移 
了 ， 一 般 都 会 提前 通知 ， 然 后 做 逐步 迁移 ， 而 且 也 肯定 不 会 让 原 集群 立即 停止 服务 。 一 般 采 用 数据 慢 慢 同步 的 方式 ， 等 到 数据 彻底 同步 完毕 ， 才 最 终 实现 切换 ， 达 到 最 终 的 迁移 目标 。 






































7.3.2 ”数据 迁移 要 素 考量 





当 准 备 做 大 规模 数据 迁移 的 时 候 ， 需 要 做 很 多 前 期 准备 工作 ， 而 且 需 要 对 很 多 因素 、 指 标 进行 考量 。 以 下 是 几 个 主要 指标 : 





1.Bandwidth : 带宽 




















在 大 规模 数据 的 同步 过 程 中 ， 如 何 控制 同步 数据 过 程 中 所 占用 的 网 络 带宽 是 十 分 重要 的 。 带 宽 用 得 多 了 ， 会 影响 到 线 上 业务 的 任务 运行 ， 带 宽 用 的 少 了 又 会 导致 数据 同步 过 慢 。 所 以 这 里 会 引发 出 另外 
一 个 问题 : 带宽 的 限 流 。 也 就 是 说 ， 我 们 要 保证 数据 同步 程序 在 限定 的 网 络 传输 速率 下 。 如 果 我 们 不 做 任何 处 理 的 话 ， 那 结果 基本 上 就 是 网 络 有 多 少 带宽 我 们 就 用 多 少 带宽 的 局 面 。 





















































2.Performance: 性 能 








性 能 问题 同样 也 是 一 个 很 关键 的 问题 ， 是 采用 简单 的 单机 程序 ? 还 是 性 能 更 佳 的 分 布 式 程序 ? 显然 后 者 是 我 们 更 想 要 的 。 








3.Data-lncrement: 增 量 同步 





当 TB、PB 级 别 的 数据 需要 同步 的 时 候 ， 如 果 每 次 以 全 量 的 方式 去 同步 数据 ， 结 果 一 定 是 非常 粮 糕 的 。 增 量 方 式 的 同步 会 是 一 个 不 错 的 选择 ， 那 么 哪些 情况 下 会 导致 数据 发 生 增 量变 动 呢 ? 有 如 下 两 类 情 
况 : 





“原始 数据 文件 进行 了 追加 写 。 


“原始 数据 文件 被 删除 或 重 命名 。 








可 能 会 有 人 好 奇 这 里 为 什么 没有 对 原始 数据 进行 改动 的 情况 ， 这 种 情况 也 会 造成 数据 的 变动 。 在 海量 数据 存储 系统 中 ， 例 如 HDFS， 一 般 不 会 在 源 文件 内 容 上 做 修改 ， 要 么 继续 追加 写 ， 要 么 删除 文件 ， 
不 会 有 类 似 RandomAccessFile 的 随机 写 的 功能 。 所 以 做 增 量 数据 同步 ， 只 要 考虑 上 述 两 个 条 件 即 可 。 上 述 条 件 中 的 第 二 点 是 非常 容易 判断 的 ， 通 过 定期 的 快照 文件 或 元 信息 文件 比较 即 可 。 但 是 对 于 文件 
是 否 进行 了 追加 写 或 是 其 他 外 界 主动 修改 操作 的 时 候 ， 我 们 如 何 进行 判断 呢 ， 下 面 给 出 两 个 判断 步骤 : 


























1) 先 比较 文件 大 小 ， 如 果 两 个 阶段 文件 大 小 发 生 改变 ， 说 明文 件 在 内 容 上 已 经 发 生变 更 ， 变 更 的 类 型 有 两 类 。 截 取 对 应 原始 长 度 部 分 进行 checksum ( 校 验 和 ) 比较 ， 如 果 此 checksum 不 变 ， 则 此 文 
件 发 生 了 追加 写 的 动作 。 如 果 checksum 发 生 改 变 ， 说 明文 件 在 原 内 容 上 也 已 经 改变 。 


2) 如 果 文 件 大 小 一 致 ， 则 计算 相应 的 checksum。 然 后 比较 两 者 的 checksum ， 如 果 两 者 checksum 一 致 ， 则 说 明文 件 内 容 没 有 发 生 改 变 。 


这 种 方式 的 比较 算得 上 是 最 保险 的 。 


4.Syncable: 数据 迁移 的 同步 性 














数据 迁移 过 程 中 需要 保证 周期 内 数据 一 定 能 够 同步 完毕 ， 不 能 差距 太 大 。 比 如 A 集 群 7 天 内 的 增 量 数据 ， 我 们 只 要 花 半 天 就 可 以 完全 同步 到 B 集 群 ， 然 后 又 可 以 等 到 下 周 再 次 进行 同步 。 最 可 怕 的 事情 在 
于 A 集 群 7 天 内 的 数据 ， 我 们 的 程序 花 了 7 天 时 间 还 同步 不 完 ， 然 后 下 一 个 周期 又 来 了 ， 这 样 就 无 法 做 到 准 实时 的 一 致 性 。 其 实 7 天 还 是 一 个 比较 大 的 时 间 ， 最 好 是 能 达到 按 天 同步 。 











7.3.3 ”HDFS 数 据 迁 移 解 决 方案 : DistCp 




















上 文 分 析 了 很 多 数据 迁移 的 使 用 场景 和 可 能 出 现 的 问题 。 但 是 从 这 里 开始 ， 将 主要 讲述 HDFS 中 的 数据 迁移 解决 方案 。 面 对 上 文中 提 到 的 诸多 问题 ， 在 HDFS 中 到 | 底 应 该 如 何 解决 呢 ? 如 果 你 不 是 
HDFS、Hadoop 的 专家 ， 可 能 问题 看 起 来 有 点 来 手 ， 但 是 没有 关系 ，Hadoop 内 部 专门 开发 了 相应 的 工具 : DistCp。DistCp 工 具 在 Hadoop 中 的 定位 就 是 用 于 数据 迁移 的 ， 针 对 的 就 是 从 源 文件 系统 到 目标 
文件 系统 的 数据 拷贝 。DistCp 在 hadoop-tools 工 程 下 ， 作 为 独立 子 工程 存在 。 在 官方 注释 中 ， 对 于 DistCp 的 解释 如 下 : 




























































































在 命令 行 的 操作 使 用 上 ，DistCp 的 main 方 法 会 解析 命令 行 中 输入 的 参数 ， 然 后 会 启动 一 个 DistCp 任 务 。 而 在 程序 层面 的 使 用 上 ， 一 个 DistCp 对 象 可 以 通过 指定 DistCpOptions 内 定义 的 一 些 参 数 进行 构 
造 ， 然 后 调用 DistCp 的 execute 方 法 来 启动 一 个 拷贝 任务 。 























大 意 是 通过 命令 行 附带 参数 的 形式 ， 构 造 出 DistCp 的 Job， 然 后 执行 此 Job。 从 这 里 可 以 知道 ， 拷 贝 任务 本 身 是 一 个 MR 的 Job， 已 经 把 Hadoop 本 身 的 分 布 式 执行 的 特性 用 上 了 。 


7.3.4 DistCp 优 势 特性 























鉴于 DistCp 的 特殊 使 用 场景 ， 程 序 设计 者 在 此 工具 代码 中 添加 了 很 多 独到 的 设计 。 下 面 针 对 上 文 提 到 的 一 些 实现 要 点 进行 相应 的 讲述 。 

















1. 带 宽 限 流 














DistCp 是 支持 带宽 限 流 的 ， 使 用 者 可 以 通过 命令 参数 bandwidth 来 为 程序 进行 限 流 ， 原 理 类 似 于 HDFS 中 数据 Balancer 程 序 的 限 流 。 但 是 笔者 认为 DistCp 做 得 比 Balancer 稍 微 简化 了 一 些 。DistCp 中 的 
相关 类 是 ThrottledlnputStream， 在 每 次 读 操作 的 时 候 ， 做 一 次 限 流 判断 : 




















/** {QinheritDoc} */ 

QOverride 

public int read () throws IOException { 
// 此 处 做 一 区 


throttle () 7 

int data = rawStream.read(); 

if (data != -1) { 
bytesRead++7 


return data; 





然后 在 throttle 的 方法 中 进行 当前 传输 速率 的 判断 ， 如 果 速 率 过 快 会 进行 一 段 时 间 的 睡眠 来 降低 总 平均 速率 : 





private void throttle() throws IOException { 
// 如 果 计算 出 当前 的 平均 速率 已 经 超过 最 大 传输 字 节 速率 ， 则 将 会 睡眠 一 段 时 间 
while (getBytesPerSec () > maxBytesPerSec) { 
try { 
Thread. sleep (SLEEP DURATION MS); 
totalSleepTime += SLEEP ”DURATION MS; 
} catch (InterruptedException e) { 
throw new IOException ("Thread aborted", e); 
} 
} 
} 








Balancer 内 部 的 限 流 原 理 ， 可 以 查阅 之 前 第 5.1 节 的 内 容 。 
2. 增 量 数 据 同 步 


对 于 增 量 数 据 同 步 的 需求 ， 在 DistCp 中 也 得 到 了 很 好 地 实现 。 通 过 update、append 和 diff 这 3 个 参数 能 很 好 地 解决 。 官 方 的 参数 使 用 说 明 如 下 : 





“Update: 更 新 目标 路 径 ， 只 拷贝 相对 于 源 端 ， 目 标 端 不 存在 的 文件 或 者 目录 。 
“ Append: 追加 写 目 标 路 径 下 已 存在 的 文件 ， 如 果 这 个 文件 在 源 端 已 经 发 生 了 追加 写 操作 。 


“ Diff:; 通过 快照 的 diff 对 比 信息 来 同步 源 端 路 径 与 目标 路 径 。 



































第 一 个 参数 ， 解 决 了 新 增 文件 、 目 录 的 同步 。 第 二 个 参数 ， 解 决 已 存在 文件 的 增 量 更 新 同步 。 第 三 个 参数 解决 删除 或 重 命名 类 型 文件 的 同步 。 这 里 diff 参 数 的 使 用 需要 设置 2 个 不 同时 间 点 的 快照 进行 对 
比 ， 产 生 相应 的 Difflnfo 信 息 。 在 获取 快照 文件 的 变化 时 ， 只 会 选择 DELETE 和 RENAME 这 两 种 类 型 的 变化 信息 。 








static DiffInfo[] getDiffs (SnapshotDiffReport report, Path targetDir) { 
List<DiffInfo> diffs = new ArrayList<>(); 
for (SnapshotDiffReport.DiffReportEntry entry : report.getDiffList()) { 
// 只 判断 删除 和 重 命名 的 类 型 
if (entry.getType () 一 SnapshotDiffReport.DiffType.DELETE) { 
final Path source = new Path (targetDir, 
DFSUtil .bytes2String (entry.getSourcePath () ) ) 7 
diffs.add (new DiffInfo(source, null)); 
else if (entry.getType() == SnapshotDiffReport.DiffType.RENAME) { 
final Path source = new Path (targetDir, 
DFSUtil .bytes2String (entry.getSourcePath () ) ) 7 
final Path target = new Path (targetDir, 
DFSUtil .bytes2String (entry.getTargetPath())); 
diffs.add (new DiffInfo(source, target)); 
} 
} 
return diffs.toArray (new DiffIinfo[ldiffs.size()]); 
} 








在 文件 数据 追加 写 的 判断 逻辑 上 ，DistCp 程 序 做 了 很 精细 的 判断 。 当 文件 大 小 不 变 的 情况 时 ， 首 先 判 断 是 否 可 以 跳 过 当前 文件 : 


Private boolean canSkip (FileSystem sourceFS, FileStatus source, 
FileStatus target) throws IOException { 
if (!syncFolders) { 


return true; 
人 
boolean sameLength = target.getLen() 一 source.getLen(); 
boolean sameBlockSize = source.getBlockSize() 一 target.getBlockSize() 
|| !preserve.contains (FileAttribute.BLOCKSIZE); 
// 如 果 是 同 大 小 并 且 blockSize 的 大 小 也 一 样 ， 则 继续 进行 checksum 的 判断 
if (sameLength && sameBlockSize) { 
return SkipCrc || 
DistCpUtils.checksumsAreEqual (SourceFS， source.getPath(), null, 
targetFS, target.getPath()); 
} else { 
return false; 
} 
} 





其 次 是 判断 是 否 可 以 进行 追加 写 : 





// 判断 是 否 可 以 跳 过 此 文件 
if (canSkip (sourceFS, source, targetFileStatus)) { 
return FileAction. ed 
} else if (append) 
// 向 末 是 提名 jn 与 的 方式 ， 首先 获取 源 目标 文件 的 大 小 
long targetLen = targetFileStatus .getLen () 
// th ee 说 明 源 文件 进行 了 新 的 写 操作 
if (targetLen < source.getLen () 
// 计生 浙 交 件 中 对 应 目标 时 天 水 的 文件 术 验 
FileChecksum sourceChecksum = Ss getFileChecksum( 
source.getPath(), targetLen); 
// 如 果 源 文件 对 应 长 度 的 数据 的 校 验 和 与 目标 文件 校 验 和 完全 一 致 ， 
// 表明 源 文件 多 出 的 数据 完全 是 新 写 入 的 ， 前 面 的 数据 没有 变动 ， 支 持 追加 写 
if (sourceChecksum != null 
&& sourceChecksum.equals (targetFS.getFileChecksum(target))) { 
// We require that the checksum is not null. Thus currently only 
// DistributedFileSystem is supported 
return FileAction.APPEND; 


} 
// 如 果 校 验 和 发 生 了 变化 ， 说 明 源 文件 前 面部 分 的 数据 发 生 了 变动 ， 则 将 会 进行 
// OVERNRITE 覆 盖 的 动作 
} 
} 
return FileAction.OVERWRITE; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








此 处 程序 并 没有 完全 将 文件 大 小 的 变化 作为 根本 依据 ， 大 小 发 生变 化 了 ， 还 要 再 对 之 前 对 应 长 度 的 数据 做 校 验 和 的 验证 。 





























在 使 用 DistCp 相 关 参 数 做 增 量 数 据 同步 的 时 候 ， 需 要 留意 部 分 参数 之 间 的 互 斥 性 。 比 如 -diff 参 数 是 根据 快照 数据 做 同步 的 ， 会 同步 AENAME 和 DELETE 两 类 关系 的 变动 。 其 中 的 DELETE 操 作 与 -delete 
参数 有 重复 的 作用 ， re 而 -delete 参 数 则 可 以 单独 使 用 。 












































3. 高 效 的 性 能 














关于 DistCp 的 性 能 问题 笔者 想 主 要 分 析 一 下 。 因 为 带宽 限 流 和 增 量 的 数据 同步 通过 普通 的 程序 优化 也 能 够 实现 。 但 是 在 性 能 特性 上 ， 笔 者 认为 DistCp 还 是 有 它 独 到 的 优势 的 。 


(1) 执行 的 分 布 式 特性 








之 前 在 上 文中 已 经 提 到 过 ，DistCp 本 身 会 构造 成 一 个 MR 的 Job。 它 是 一 个 纯 由 Map 任 务 构成 的 Job， 注 意 它 是 没有 Reduce 过 程 的 。 所 以 它 能 够 把 集群 资源 利用 起 来 ， 集 群 闲 下 来 的 资源 越 多 ， 它 运行 
得 就 越 快 。 下 面 是 DistCp Job 的 构造 过 程 : 














// 根据 当前 配置 创建 一 个 新 的 Job 
Private Job createJob () throws IOException { 
// DistCp Job 统 一 名 称 为 distcp” 
String jobName = "distcp"; 
String userChosenName = getConf () .get (JobContext .JOB NAME); 
if (userChosenName != null) > 
jobName += ": " + userChosenName; 
Job job = Job.getInstance (getConf () ) ; 
Job .setJobName (jobName) 7 
job.setInputFormatClass (DistCpUtils.getStrategy (getConf (), inputOptions)); 
job. setJarByClass (CopyMapper .class); 
configureOQutputFormat (job); 
// 设置 特殊 定制 的 CopyMapper 的 map 类 型 
job.setMapperClass (CopyMapper .class); 
// 无 Reduce Task 
job.setNumReduceTasks (0); 
job.setMapOutputKeyClass (Text .class); 
job.setMapOutputValueClass (Text .class); 
job.setOutputFormatClass (CopyOutputFormat .class); 
job.getConfiguration() .set (JobContext .MAP SPECULATIVE, "false"); 
job.getConfiguration() .set (JobContext.NUM MAPS, 
String.valueOf (inputOptions.getMaxMaps 这 


if (inputOptions .getSsl1ConfigurationFile() != null) { 
setupSSLConfig (job) 7 


inputOptions.appendToConf (job.getConfiguration ()) 7 
// 返回 构造 好 的 Job 


return job; 





(2) 高 效 的 MR 组 件 


高 效 的 MR 组 件 的 指 的 是 DistCp 在 相应 的 Job 中 提供 了 针对 此 类 型 任务 独 有 的 Map 类 、InputFormat 和 OutputFormat， 分 别 是 CopyMapper、DynamiclnputFormat 和 CopyOutput-Format。 这 三 种 
MR 组 件 类 型 与 普通 的 MR 类 型 有 什么 区 别 呢 ? 答案 如 下 所 示 : 





“ 在 HDFS 上 拆 分 拷贝 列表 到 更 小 粒度 单元 的 chunk。 
: 创建 一 个 空 的 动态 的 spilt 分 片 ， 以 此 让 每 个 任务 可 以 消费 尽 可 能 多 的 chunk。 


以 上 强调 了 两 点 ，DynamiclnputFormat 类 会 将 输入 文件 分 成 很 多 小 的 chunk， 然 后 由 这 些 chunk 构 成 动态 的 分 片 ， 尽 可 能 地 让 Map 任 务 消 费 掉 。 而 不 是 按照 传统 的 方式 将 输入 文件 分 割 成 固定 的 分 
片 。 前 者 不 会 造成 任何 慢 的 Map 任 务 拖累 整个 Job 的 运行 。 保 证 了 哪个 Map 任 务 消费 得 快 ， 那 就 消费 更 多 分 片 的 原则 。 其 中 具体 的 原理 实现 读者 可 自行 到 org.apache.hadoop.tools.mapred.lib 包 下 的 代码 
中 进行 分 析 。 图 7-4 为 DistCp Job 的 组 成 结构 。 
































CopyMapper 


7.3.5 Hadoop DistCp 命 令 


DynamicinputFormat Input-filles 


createRecordReader 


DynamicinputChunk 


create spilt 


DynamicRecordReader 


InputSplit 


图 7-4 DistCp Job 结 构图 




















前 面 花 了 大 量 的 篇 幅 讲 述 了 DistCp 工 具 的 强大 用 处 ， 最 后 给 出 使 用 帮助 信息 ， 输 入 hadoop distcp 命 令 即 可 获取 ， 以 下 列 出 几 个 常用 的 操作 命令 : 


CopyOQutputFormat 





CopyCommitter 









usage: distcp OPTIONS [source pathhttp://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 

















则 直接 覆盖 
块 大 小 信息 等 等 


$ hadoop distcp 
OPTIONS 

-append // 拷贝 文件 时 支持 对 现 有 文件 进行 追加 写 操作 
-async // 异步 执行 distcp 拷 贝 任务 

-bandwidth <arg> // 对 每 个 Map 任 务 的 带宽 限 速 

-delete // 删除 相对 于 源 端 , Ss 

-diff <arg> 照 行 数据 的 同步 

-overwrite // 人 和 只 目标 端 文件 已 经 存在 ， 
-p <arg> 数据 时 ， 性 信 息 的 保留 ， 包 括 权限 信息 、 
-skipcrccheck & 的 校 验 

-update // 找 妈 据 时 ， 只 拷贝 相对 于 尖端 ， 目标 端 不 存在 的 文件 数据 


.] <target path> 








其 中 source_path、target_path 需 要 带 上 地 址 前 缀 以 区 分 不 同 的 集群 ， 例 如 : 





hadoop distcp hdfs://nn1:8020/foo/a hdfs://nn2:8020/bar/foo 





上 面 的 命令 表示 从 nn1 集 群 拷贝 /foo/a 路 径 下 的 数 


跳 过 校 验 和 可 能 会 影响 到 DistCp 数 据 完 整 性 的 判断 ， 但 | 


当然 跨 机 房 数据 迁移 的 工作 一 定 还 会 出 现 没有 预见 到 的 问题 ， 其 中 的 难度 和 困 





7.3.6 ”DistCp 解 决 集群 间 数 据 迁移 实例 


下 面 分 享 的 是 笔者 在 实际 工作 中 











用 distcp 命 令 做 不 同 数据 中 心 之 间 数 据 同步 的 实际 例子 。 数 据 同 步 的 场景 分 为 以 下 两 类 : 























第 一 类 ， 源 端 集群 数据 不 会 发 生变 更 ， 是 一 堆 静 态 数据 。 这 种 同步 方式 很 简单 ， 用 distcp 命 令 指明 好 源 集群 、 目 标 集群 地 址 ， 对 想 要 同步 数据 的 最 顶层 目录 进行 同步 即 可 。 











第 二 类 ， 源 端 集群 数据 会 时 时 变化 更 新 。 这 种 情况 下 ， 可 以 采用 快照 的 方式 进行 同步 : 


1) 首先 在 源 集群 的 目标 拷贝 目录 上 创建 一 个 快照 。 











2) 然后 入 


3) 等 第 一 轮 的 快照 同步 结束 之 后 ， 


用 distcp 同 步 此 快照 到 目 


件 再 次 进行 扫描 同步 。 


4) 以 此 类 推 ， 当 最 终 源 














笔者 在 做 数据 同步 的 过 程 中 也 不 是 一 帆 风 顺 的 ， 其 中 也 踩 了 不 少 坑 。 


比如 说 在 拷贝 数据 文件 的 时 候 ， 如 果 没 有 仔细 注意 拷贝 路 径 的 设 


可 以 在 源 集群 上 的 同样 目录 下 创建 第 二 个 


录 和 集群 ， 第 一 轮 的 同步 过 程 是 最 花 时 间 的 ， 所 以 需要 等 待 一 段 时 间 。 














端 创建 的 快照 与 目标 集群 的 数据 几乎 没有 太 大 差别 的 时 候 ， 就 可 以 做 一 次 切换 ， 将 集群 地 址 从 源 集群 切 到 目标 集群 。 











快照 ， 再 次 做 数据 同步 ， 但 是 这 个 时 候 可 以 使 用 一 些 -delete、-update 的 参数 来 同步 发 生变 更 的 数 所 


难 绝对 是 非常 具有 挑战 性 的 。 可 能 我 们 还 要 利用 DistCp 的 功能 然后 搭配 上 自己 的 解决 方案 才能 做 出 更 棒 的 方案 。 


居 到 nn2 集 群 的 /bar/foo 路 径 下 。 总 体 而 言 ，DistCp 的 可 选 参 数 还 是 做 到 了 相当 细 粒 度 的 控制 ， 比 如 skipcrccheck 的 选项 ， 可 以 跳 过 校 验 和 的 校 验 。 
同时 此 配置 的 关闭 会 使 得 拷贝 过 程 更 加 高 效 。 


居 文 件 ， 而 不 是 所 有 文 


， 会 很 容易 造成 拷贝 文件 位 置 出 错 的 情况 ， 比 如 文件 拷贝 到 了 目标 路 径 的 子 目录 中 。 第 二 类 情况 是 集群 中 丢失 的 块 会 导致 distcp 拷 贝 


任务 的 失败 退出 。 这 个 现象 非常 隐蔽 ， 丢 失 的 块 在 一 般 情况 下 只 会 导致 部 分 任务 的 数据 拷贝 失败 ， 但 是 distcp 程 序 会 把 在 运行 的 任务 全 部 停止 运行 。 在 这 点 上 ， 笔 者 觉得 此 做 法 稍 显 不 受 ， 毕 竟 distcp 启 动 运 
行 一 次 成 本 是 比较 高 的 。 所 以 在 数据 同步 的 过 程 中 ， 要 及 时 留意 NameNode 页 面 上 是 否 有 丢失 或 损坏 的 块 。 如 果 存 在 则 尽快 用 fsck<path > -delete 进 行 





属性 信息 的 保留 ， 





可 以 





用 -p 加 上 想 要 保留 


7.4 ”DataNode 汗 移 方 案 





属性 的 对 应 参数 。 





因 











为 如 果 没 有 保留 





属 





性 信息 的 话 ， 拷 贝 到 目标 集群 的 数据 在 运行 任务 的 时 候 可 能 会 造成 文件 所 





在 数据 同步 的 过 程 中 ， 




















属 上 








户 读 写 数据 失败 的 情况 。 


需要 注意 数 拉 





居 权 限 等 








本 节 标 题 所 示 的 DataNode 迁 移 并 不 是 指 DataNode 上 的 数据 迁移 ， 而 是 指 DataNode 自 身 节点 的 搬迁 。 在 搬迁 的 过 程 中 ， 此 节点 将 会 停止 服务 ， 搬 迁 完 成 后 ， 还 可 能 涉及 主机 名 、ip 地 址 的 变化 。 本 节 





























所 要 讲述 的 就 是 此 过 程 的 迁移 方案 。 一 种 情况 是 更 换 主机 名 、ip 地 址 的 情况 ， 另 一 种 是 不 更 新 主机 名 、ip 地 址 情况 。 本 节 介 绍 第 一 种 情况 。 


7.4. 


1. 目 








1 迁移 方案 的 目标 


标 














数据 不 











由 于 外 界 因素 的 影响 ， 需 要 将 原 DataNode 所 在 节点 的 机 器 从 A 机 房 换 到 B 机 房 ， 其 中 会 涉及 主机 名 和 ip 地 址 的 改变 。 最 终 的 目标 是 DataNode 迁 移 之 后 对 集群 不 造成 大 的 影响 ， 服 务 依然 可 








发 生 丢 失 。 


2. 相 关 知 识 





因为 在 DataNode 迁 移 的 时 候 ， 必 定 会 导致 迁移 节点 停止 心跳 ， 如 果 超 过 心跳 检查 超时 时 间 ， 此 节点 就 会 被 NameNode 认 为 是 死 节点 。 为 了 满足 块 副本 数 要 求 ， 会 造成 集群 内 大 量 块 复制 的 现象 。 如 果 





想 要 在 短 时 间 内 不 使 节点 成 为 死 节点 ， 需 要 人 工 把 心跳 超时 检查 时 间 设 大 。NameNode 超 时 心跳 检测 时 间 算 法 如 下 : 





DatanodeManager (final BlockManager blockManager, final Namesystem namesystem, 
final Configuration conf) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teach 


final long heartbeatIntervalSeconds = conf.getLong( 
DFSConfigKeys.DFS HEARTBEAT INTERVAL KEY, 
DFSConfigKeys . DFS HEARTBEAT INTERVAL | , DEFAULT); 
final int heartbeatRecheckInterval = conf. getInt( 
DFSConfigKeys.DFS NAMENODE HEARTBEAT RECHECK INTERVAL KEY, 
DFSConfigkKeys. DFS NAMENODE ,HEARTBEAT | ”RECHECK INTERVAL ] , DEFAULT); // 5 minutes 
// 心跳 检测 超时 时 间 的 计算 
this.heartbeatExpireInterval = 2 * heartbeatRecheckInterval 
+ 10 * 1000 * heartbeatIntervalSeconds; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teach 





核心 公式 如 下 : 
this.heartbeatExpirelnterval=2*heartbeatRechecklnterval+ 
10*1000*heartbeatlntervalSeconds 


heartbeatRechecklnterval 心 跳 检 测 时 间 默 认 300 秒 ， 心 跳 间 隔 时 间 3 秒 ， 默 认 超时 时 间 2x300+10x3=630 秒 ， 因 此 需要 将 前 者 配置 加 大 。 











</property> 

<name>dfs.namenode.heartbeat .recheck-interval</name> 
<value>10800000</value> 

</property> 





























述 的 配置 表明 将 此 值 调 大 为 3 小 时 ， 这 个 值 可 以 根据 使 用 场景 进行 变化 。 执 行 以 下 操作 可 以 使 此 配置 值 生效 。 








“ 更 新 standby namenode 的 hdfs-site.xml 的 配置 ， 并 重启 。 


“ 等 待 standby namenode 退 出 safemode 之 后 ， 再 stop active namenode， 更 新 配置 并 重启 。 











但 是 此 种 方案 适用 于 DataNode 不 涉及 主机 名 和 ip 地 址 变化 的 情况 。 








下 面 是 涉及 主机 名 、ip 地 址 变化 情况 的 迁移 方案 。 





7.4.2 ”DataNode 更 换 主机 名 、ip 地 址 时 的 迁移 方案 


步骤 1: DataNode 迁 移 测试 





在 DataNode 做 迁移 之 前 ， 进 行 测试 文件 的 上 传 和 RPC 请 求 的 测试 ， 为 了 与 后 面 的 测试 结果 进行 对 比 。 











首先 上 传 1 个 test 文 件 : 





bin/hadoop fs -put test.txt /tmp 














保证 此 文件 所 在 的 块 存在 于 此 节点 上 ， 用 -cat 命 令 进行 查看 : 








bin/hadoop fs -cat /tmp/test.txt 





测试 完毕 ， 此 时 停止 DataNode， 并 使 用 ps 命令 查看 此 DataNode 是 否 真 正 停止 。 





并 观察 NameNode 的 Web 界 面 ， 在 时 间 超 过 630 秒 后 ， 迁 移 节点 将 被 显示 为 dead 状 态 ， 意 为 死 节点 。 


之 后 在 NameNode Web 界 面 的 待 复制 块 (Number of Under-Replicated Blocks) 指标 将 会 显示 正在 进行 拷贝 的 块 副本 数 ， 表 明 目 前 有 大 量 的 块 在 进行 副本 复制 。 





步骤 2: DataNode 重 启 



































新 启动 DataNode， 查 看 DataNode 输 出 日 志 。DataNode 在 初次 启动 的 时 候 由 于 缓存 的 dfsUsed 值 超过 600 秒 会 过 期 ， 需 要 重新 执行 du 命令 扫描 DataNode 上 面 的 磁盘 块 进行 dfsUsed 使 用 量 的 计 
会 消耗 几 分 钟 的 时 间 (如 果 是 立即 停止 ， 并 马上 重启 DataNode， 将 会 非常 快 ) ， 日 志 如 下 : 


























2016-01-06 16:05:08,181 INFO org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl: Scanning block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on volume /home/ds 
2016-01-06 16:05:08,181 INFO org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl: Scanning block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on volume /home/ds 
2016-01-06 16:09:49,646 INFO org.apache.hadoop.hdfs.server.datanode.fsdataset.impl .FsDatasetImpl: Time taken to scan block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on /home 
2016-01-06 16:09:54,235 INFO org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl: Time taken to scan block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on /home 











出 现 上 述 “Time taken” 开 头 的 日 志 代表 磁盘 扫描 操作 结束 ，DataNode 启 动 成 功 了 。 








“ DataNode 成 功 启动 后 ，NameNode 页 面 上 的 待 复制 块 指标 将 会 重新 变 为 0 或 比较 小 的 一 些 数值 ， 比 如 几 十 或 几 百 ， 分 别 代表 不 需要 和 极 少 需 要 额外 副本 块 的 复制 ， 这 些 都 属于 正常 的 情况 。 


“ 在 此 节点 上 重新 执行 bin/hadoop fs-cat/tmp/test.txt 命 令 ， 测 试 文件 内 容 是 否 还 能 够 查看 ， 测 试 结 束 后 删除 测试 文件 。 
迁移 方案 总 结 : 
“ 对 于 更 换 主机 名 和 ip 地 址 的 DataNode 迁 移 操 作 而 言 ， 只 要 在 可 控 的 时 间 内 恢复 DataNode 服 务 即 可 ， 不 会 对 集群 造成 大 的 影响 ， 只 会 在 迁移 节点 成 为 死 节 点 的 状态 时 才 会 出 现 短暂 块 复制 的 现象 。 


“ 对 于 不 变化 主机 名 和 ip 地 址 情况 的 DataNode 迁 移 操 作 ， 只 要 加 大 心跳 检测 时 间 ， 使 其 在 短 时 间 内 不 成 为 死 节 点 ， 然 后 进行 恢复 即 可 ， 此 操作 将 不 会 对 集群 造成 影响 。 心 跳 检测 时 间 配 置 项 为 


dfs.namenode.heartbeat.recheck-interva ， 默 认 单 位 为 毫秒 。 


7.5 ”HDFS 集 群 重 命名 方案 





在 部 分 集群 数据 迁移 之 后 ， 有 时 需要 维持 新 老 集群 名 称 的 一 致 ， 否 则 会 出 现 客户 端 程序 读 写 数据 异常 的 现象 。 但 是 由 于 在 搭建 新 集群 的 时 候 并 未 预见 此 状况 的 发 生 ， 已 经 确定 好 了 集群 名 称 。 这 个 时 候 
我 们 该 怎么 办 ? 本 节 所 要 讲述 的 HDFS 集 群 重 命名 方案 就 是 为 了 解决 这 个 问题 。 本 节 通 过 操作 步骤 的 形式 来 讲述 重 命名 方案 ， 在 每 个 步骤 中 会 介绍 具体 的 操作 行为 或 执行 命令 。 

















第 一 步 : 停止 集群 所 有 服务 





因为 涉及 HDFS 集 群 名 称 的 变更 ， 所 以 HDFS 相 关 的 服务 一 定 得 停止 ， 其 次 为 了 避免 其 他 的 影响 ,最 好 把 YARN 相 关 的 服务 也 停止 。 








$sbin/stop-dfs.sh 
$sbin/stop-yarn.sh 





第 二 步 : 修改 HDFS 集 群 名 称 相关 配置 
此 步骤 中 涉及 了 3 个 配置 文件 的 变更 ， 分 别 为 core-site.xml、hdfs-site.xml 和 yarn-site.xml。 原 集群 名 称 假设 为 clusterA， 目 标 名 称 为 clusterB。 下 面 为 这 3 个 文件 的 变更 修改 。 


1) core-site.xml 





<property> 
<name>fs.defaultFS</name> 
<value>hdfs://clusterA</value> 
<final>true</final> 
</property> 





此 处 将 hdfs://clusterA 蔡 换 为 hdfs://clusterB 即 可 。 


2) yarn-site.xml 





因为 YARN 部 分 应 用 相关 的 数据 也 会 存放 在 HDFS 之 上 ， 所 以 这 部 分 的 配置 也 是 需要 更 新 的 。 如 下 配置 所 示 : 








<property> 
<name>yarn.resourcemanager.fs.state-store.uri</name> 
<value>hdfs://clusterA/logs/yarn/rmstore</value> 
</property> 


同 理 ， 将 clusterA 进 行 替换 。 


3) hdfs-site.xml 





hdfs-site 文 件 无 疑 是 配置 属性 变更 最 多 的 一 个 文件 。 


<property> 
<name>dfs.nameservices</name> 
<value>clusterA</value> 

</property> 

<property> 
<name>dfs.ha.namenodes.clusterA</name> 
<value>nnl, nn2</value> 

</property> 

<property> 
<name>dfs .namenode .rpc-address.clusterA.nnl</name> 
<value>clusternn1:9000</value> 

</property> 

<property> 
<name>dfs.namenode .rpc-address.clusterA.nn2</name> 
<value>clusternn2:9000</value> 

</property> 

<property> 
<name>dfs.namenode.http-address.clusterA.nnl</name> 
<value>clusternn1:50070</value> 

</property> 

<property> 
<name>dfs.namenode.http-address.clusterA.nn2</name> 
<value>clusternn2:50070</value> 

</property> 

<property> 
<name>dfs.client.failover.proxy.provider.clusterA</name> 
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> 

</property> 











这 里 的 clusterA 全 部 替换 为 目标 名 称 clusterB。 























自 此 ， 所 有 相关 配置 项 都 已 更 改 完毕 。 但 是 这 里 还 需要 执行 下 一 个 关键 的 步骤 。 











第 三 步 : 





格式 化 HDFS 所 依赖 的 znode 


这 步 操作 是 操作 者 经 常 容易 忘记 的 ， 没 有 操作 过 的 人 可 能 不 会 想到 ，NameNode 会 把 自身 的 集群 名 称 与 znode 进 行 关联 。 





如 果 没 有 重新 执行 format znode 的 操作 ， 在 重启 NameNode 的 时 候 会 出 现下 面 的 错误 : 








/10.11.2.81:2181, sessionid = 0x51535b491d5e0ab8, negotiated timeout = 30000 

2016-05-16 15:27:21,087 INFO [main-EventThread] (ActiveStandbyElector.java:547) - Session connected. 

2016-05-16 15:27:21,095 FATAL [main] (ZKFailoverController.java:219) - Unable to start failover controller. Parent znode does not exist. 
Run with -formatZK flag to initialize ZooKeeper. 


2016-05-16 15:27:21,103 INFO [main] (ZooKeeper.java:684) - Session: 0x51535b491d5e0ab8 closed 
2016-05-16 15:27:21,103 INFO [main-EventThread] (ClientCnxn.java:512) - EventThread shut down 














其 中 提示 parent znode 没 有 找到 ， 同 时 建议 我 们 执行 -formatZK 的 操作 。 这 个 错误 会 导致 zkfc 进 程 启动 失败 ， 继 而 两 个 NameNode 的 Active、Standby 切 换 将 会 失败 ， 你 会 看 到 同时 出 现 两 个 Standby 
NameNode 的 场景 。 最 后 只 能 通过 手动 切换 的 方式 选 出 一 个 节点 作为 Active NameNode。 为 什么 会 出 现 这 样 的 错误 呢 ? 这 个 得 要 亲自 到 zk 上 去 查看 ， 才 能 明白 其 中 的 原因 ， 我 们 用 zk 客户 端 命令 查看 相关 
znode 节 点 ， 结 果 如 下 : 
























































[zk: xx.xx.xx.xx:2181 (CONNECTED) 2] 1s /hadoopTestCluster-hadoop-ha 
[clusterA] 





从 这 里 可 以 看 到 ， 在 HDFS 所 关联 的 znode 子 节点 中 ， 会 把 当前 集群 名 称 作为 子 节点 的 名 称 。 再 次 查看 里 面 存放 的 内 容 : 











[zk: xx.xx.xx.xx:2181 (CONNECTED) 8] get /hadoopTestCluster-hadoop-ha/clusterA/ActiveBreadCrumb 
ClusterAxxxx F(> 

c2xid = 0x9000000a3 

ctime = Wed Mar 02 15:41:23 CST 2016 
m2Zxid = 0x9002937dd 

mtime = Mon May 16 15:40:02 CST 2016 
Pp2Zxid = 0x9000000a3 

cversion = 0 

dataVersion = 17 

aclVersion = 0 

ephemeralOwner = 0x0 

dataLength = 33 

numChildren = 0 











在 以 集群 名 为 名 称 的 子 节点 中 就 存放 了 Active NameNode 的 主机 名 以 及 其 他 相关 的 信息 。 这 个 节点 名 称 在 第 一 次 zk format 的 时 候 就 确定 下 来 了 ， 倘 若 集群 更 换 了 名 称 ， 自 然 就 找 不 到 对 应 的 znode 








所 以 要 解决 这 个 问题 ， 还 是 要 重新 执行 fotmat znode 操 作 。 首 先 停 止 HDFS 相 关 服 务 ， 然 后 执行 format 命 令 : 





hdfs zkfc -formatZK 





确认 操作 没有 出 现 异 常 后 ， 执 行 下 面 的 验证 操作 。 如 果 都 进行 顺利 的 话 ，HDFS 重 命名 操作 就 算 成 功 了 。 





Man 





“ 重启 HDFS 相 关 服 务 。 
“ 执行 hadoop 的 全 命令 是 否 可 用 。 


“ 最 后 启动 YARN 相 关 的 服务 ， 并 提交 一 个 wordcount 任 务 到 YARN 上 做 测试 。 


7.6 ”HDFS 的 配置 管理 方案 


























HDFS 配 置 管理 方案 所 要 解决 的 问题 是 HDFS 的 配置 管理 问题 。 在 集群 规模 越发 庞大 的 情况 下 ，HDFS 的 配置 管理 往往 越 难 。 在 其 间 会 遇 到 两 大 问题 : 第 一 ， 集 群 的 异 构 性 造成 配置 的 多 样 化 ; 第 二 ， 多 
人 维护 配置 导致 配置 变更 记录 难以 维护 。 本 节 将 为 大 家 介绍 一 种 基于 Git 的 简单 配置 管理 方案 。 在 此 方案 中 ， 我 们 巧妙 地 利用 了 Git 本 身 具 有 的 历史 版 本 记录 的 功能 。 在 方案 讲述 的 过 程 中 ， 还 将 会 介绍 现 有 
配置 管理 存在 的 问题 以 及 目前 用 于 配置 管理 的 一 些 开源 工具 。 
























































7.6.1 _HDFS 配 置 管理 的 问题 


























当 集 群 规模 日 益 扩 张 ， 渐 渐 地 我 们 会 碰 到 一 些 配置 管理 上 的 问题 。 有 人 可 能 会 有 疑问 ， 集 群 扩容 的 时 候 ， 都 是 用 相同 的 安装 包 部 署 ， 配 置 不 都 是 一 样 的 吗 ” 为 什么 还 会 磁 到 配置 管理 的 问题 ” 当 看 完 这 
段 文字 ， 作 为 一 名 运 维 工程 师 ， 如 果 你 也 是 这 么 想 的 话 ， 那 只 能 说 明 一 个 问题 : 你 管理 的 集群 规模 还 不 够 大 或 者 是 你 的 集群 变更 操作 太 少 ， 节 点 部 署 完了 ， 基 本 就 不 动 它 了 (这 里 不 包括 常用 的 启动 和 停止 
服务 操作 ) 。 下 面 来 重点 谈 谈 集群 规模 变 大 会 给 配置 管理 带 来 的 两 个 主要 问题 。 





















































“ 配置 的 差异 化 管理 。 随 着 集群 规模 的 扩大 ， 会 不 断 有 新 节点 加 入 。 但 是 新 扩容 节点 的 机 型 并 不 保证 都 与 现 有 节点 完全 一 致 。 而 且 有 时 我 们 也 需要 一 些 异 构 的 机 器 来 做 相应 的 异 构 存储 ， 比 如 最 常见 的 
冷 热 数据 的 分 类 存储 。 这 时 我 们 需要 一 些 拥 有 高 密度 存储 特性 但 计算 性 能 不 是 很 高 的 机 器 。 机 型 的 不 同 会 带 来 一 个 直接 的 变化 ， 就 是 配置 的 不 同 。 以 异 构 存 储 为 例 ， 如 果 集群 中 一 部 分 机 器 被 用 做 冷 数据 的 
存储 ， 它 的 数据 目录 的 配置 一 般 会 带 上 [ARCHIVE] 标 签 。 而 普通 机 器 在 此 配置 项 上 就 可 以 直接 写 存储 目录 的 位 置 ， 这 就 会 带 来 一 个 配置 的 差异 。 当 然 ， 还 有 更 常见 的 内 存 、 磁 盘 数 、 核 数 等 差异 。 而 配置 的 
差异 化 会 给 集群 的 管理 带 来 不 小 的 麻烦 。 因 为 此 时 集群 运 维 人 员 需 要 维护 多 份 配 置 ， 然 后 根据 对 应 机 型 的 节点 来 分 发 对 应 的 配置 ， 这 样 不 利于 做 到 批量 处 理 。 在 多 份 配置 的 情况 下 ， 有 的 时 候 还 会 导致 人 工 
的 误 操 作 。 


“ 配置 的 历史 记录 管理 。 配 置 的 历史 记录 管理 指 的 是 配置 的 变更 管理 。 如 果 集群 维护 人 员 就 只 有 1、2 个 人 的 时 候 ， 配 置 的 变更 可 能 不 会 出 现 很 大 的 问题 。 但 是 如 果 集群 是 在 多 人 维护 的 情况 下 ， 可 能 会 
发 生 配置 变更 信息 不 同步 的 问题 。 比 如 集群 管理 人 员 有 A、B、C、D 四 人 。 某 天 A 因 为 集群 出 了 问题 ， 临 时 改 了 集群 配置 ， 但 没有 及 时 通知 B、C、D。 过 了 一 个 月 B、C、D 三 人 才 突 然 发 现 配置 已 发 生变 更 ， 
然后 询问 到 A， 发 现 是 他 做 的 操作 。 但 是 A 已 经 记 不 得 当时 他 具体 改 的 是 什么 配置 项 了 。 这 就 会 造成 配置 变更 记录 的 丢失 。 


以 上 两 点 问题 主要 在 集群 规模 比较 大 的 时 候 容易 显现 出 来 。 


7.6.2” 现 有 配置 管理 工具 















































针对 以 上 问题 ， 目 前 是 否 有 现成 的 工具 能 够 帮助 我 们 解决 配置 管理 的 问题 呢 ? 答案 是 有 的 。 目 前 比较 流行 的 工具 有 2 个 : Chef 和 Puppet。 这 2 个 工具 笔者 都 使 用 过 ， 但 是 Chef 会 更 加 熟悉 一 些 。 所 以 这 
里 主要 分 享 笔者 使 用 Chef 做 集群 配置 管理 的 一 些 体会 。 


















































第 一 点 ， 学 习 成 本 较 高 。 这 些 开 源 工具 并 不 是 拿 来 立即 就 能 使 用 的 ， 用 户 至 少 需要 了 解 开源 工具 的 操作 流程 ， 同 时 最 好 也 要 了 解 它 的 相关 原理 设计 。 


















































第 二 点 ， 需 要 投入 时 间 去 学 习 与 使 用 。 笔 者 在 使 用 Chef 做 集群 配置 管理 的 时 候 ， 是 看 中 了 它 的 历史 版 本 管理 的 功能 以 及 动态 生成 配置 的 功能 。 但 是 如 果 你 想 很 好 地 使 用 它 ， 还 是 需要 投入 一 些 时 间 进 
去 ， 而 且 要 不 断 地 去 实践 。 否 则 ， 你 可 能 只 是 仅仅 用 到 了 它 的 一 小 部 分 功能 而 已 ， 还 不 如 我 们 写 个 脚本 批 处 理 程序 执行 一 遍 来 得 快 。 

























































































总 而 言 之 ， 对 于 开源 工具 的 使 用 ， 笔 者 认为 不 在 于 它 本 身 是 多 么 完美 、 好 用 ， 而 是 在 于 用 户 是 否 能 够 花 时 间 、 人 力 去 把 它 用 好 。 用 好 了 ， 自 然 就 能 发 挥 它 的 功能 ， 如 果 用 不 好 ， 那 还 是 建议 用 我 们 更 加 
熟悉 的 方式 来 做 ， 例 如 自己 开发 一 套 配 置 管理 系统 。 






































7.6.3 ”运用 Git 来 做 配置 管理 





有 什么 办 法 可 以 让 我 们 以 最 低 的 成 本 来 做 配置 管理 这 件 事情 呢 ? 我 们 马上 可 以 联想 到 Git。 因 为 Git 对 于 我 们 来 说 非常 熟悉 ， 而 且 它 与 Svn 类 似 ， 可 以 做 项 目的 管理 。 所 以 在 这 节 中 ， 我 们 尝试 使 用 Git 来 
做 集群 配置 管理 的 解决 方案 。 由 于 Git 本 身 的 特点 ， 它 可 以 直接 帮助 我 们 解决 配置 记录 变更 的 问题 ， 通 过 git log 命 令 能 找到 所 有 的 提交 记录 。 但 是 另外 一 个 问题 ， 也 就 是 配置 的 差异 管理 ， 这 个 需要 我 们 自己 
想 办 法 进行 解决 。 

























































































假设 我 们 已 经 在 Git 上 创建 好 了 一 个 工程 ， 里 面 的 内 容 就 是 待 管理 的 配置 文件 。 在 这 种 情况 下 我 们 如 何 做 到 配置 的 差异 化 管理 呢 ? 首先 一 点 ， 我 们 需要 明白 会 存在 哪些 差异 点 ， 然 后 再 对 配置 的 目录 结构 
做 调整 。 在 前 面 的 内 容 中 ， 我 们 提 到 了 其 中 一 个 差异 点 : 机 型 的 差异 。 其 实 如 果 把 考虑 范围 放大 ， 还 会 有 如 下 的 差异 点 : 





























“ 集群 归属 差异 。 可 能 你 所 维护 的 集群 不 止 一 个 ， 并 且 不 同 集群 分 布 在 不 同 的 机 房 内 ， 这 里 就 会 有 集群 本 身 的 差异 。 
: 版 本 的 差异 。 如 果 集 群 未 来 会 进行 升级 操作 ， 势 必 会 带 来 版 本 的 变化 。 新 老 版 本 的 配置 之 间 会 存在 一 定 的 差别 。 
结合 以 上 提出 的 3 点 差异 性 ， 我 们 可 以 对 Git 配 置 项 工程 进行 如 下 的 设计 : 


branch:clusterA—-/versions/2.7.1/64G/etc 














对 于 集群 自身 的 不 同 ， 我 们 可 以 以 branch 分 支 做 区 分 。 然 后 是 versions 版 本 目录 ， 在 此 目录 下 是 针对 多 个 版 本 的 配置 项 ， 如 果 Hadoop 以 后 发 布 了 2.8.0 版 本 ， 我 们 就 可 以 加 在 此 目录 下 。 接 下 来 是 机 型 
的 差异 ， 机 型 的 差异 通过 64G、128G 等 带 有 特征 性 的 名 称 做 区 分 ， 这 里 的 64G 指 的 是 64GB 内 存 的 节点 。 在 机 型 的 子 目录 中 ， 才 是 最 终 存放 的 目录 。 这 里 etc 目 录 实 质 上 就 是 Hadoop 安 装 包 下 的 etc 目 录 。 







































































配置 项 过 程 设 计 好 了 ， 我 们 如 何 将 它 运用 到 实际 的 工作 中 去 呢 ? 直接 放 到 Hadoop 安 装 包 下 ? 这 样 显然 是 不 行 的 ， 因 为 目录 结构 已 经 完全 不 同 了 。 所 以 解决 的 办 法 是 通过 软 链接 的 形式 。 将 节点 中 
Hadoop 安 装 包 中 的 etc 目 录 软 链接 到 上 面具 体 机 型 下 的 etc 目 录 ， 效 果 如 下 : 







































































hadoop-current/etc -> /versions/2.7.1/64G/etc 

















当 我 们 想 要 做 配置 的 变更 时 ， 只 要 在 本 地 机 器 上 修改 这 个 Git 工 程 项 目 ， 进 行 提交 ， 然 后 在 集群 中 的 某 台 机 器 上 做 git pull 批 量 更 新 动作 即 可 。 以 后 我 们 的 运 维 人 员 就 不 需要 再 登录 机 器 去 改 配置 了 。 















































本 节 所 述 的 配置 管理 方案 算 不 上 是 什么 复杂 的 方案 ， 主 要 还 是 与 大 家 讨论 一 下 在 集群 维护 中 的 配置 管理 问题 ， 以 及 我 们 是 否 有 好 的 办 法 去 解决 它 ， 希 望 能 够 给 大 家 带 来 一 些 启发 性 的 思考 。 





7 小结 














本 章 讲述 了 关于 HDFS 数 据 管理 的 多 个 实践 方案 。 不 同方 案 之 间 由 于 难度 不 相同 ， 所 花 的 篇 幅 也 差别 较 大 。 其 中 HDFS 的 数据 规模 监控 在 实际 运 维 中 是 比较 重要 的 一 点 ， 这 样 的 数据 对 于 我 们 进行 集群 规 
模 的 扩容 具有 十 分 重要 的 参考 意义 。 而 HDFS 的 数据 迁移 方案 无 疑 是 本 章 的 一 个 难点 ， 如 何 做 到 数据 的 准 实时 同步 是 其 中 一 个 非常 关键 的 步骤 。 
































第 8 章 ”HDFS 的 数据 读 写 


























本 章 我 们 将 会 介绍 两 个 局 部 的 改造 。 与 前 一 章 不同 ， 本 章 的 改造 内 容 需要 基于 Hadoop 源 代码 进行 ， 改 造 的 目标 对 象 都 是 磁盘 。 因 为 HDFS 每 天 的 读 写 操作 都 会 经 过 磁盘 ， 所 以 对 其 进行 优化 、 改 造 也 是 
必 不 可 少 的 。 本 章 将 会 介绍 两 方面 的 改造 ， 第 一 ， 磁 盘 选 择 策略 的 改造 ， 目 前 是 采用 轮 询 的 方式 进行 磁盘 的 选择 。 第 二 ，“ 慢 磁盘 ”的 监控 改造 ， 此 监控 能 够 让 我 们 马上 发 现 “ 慢 磁盘 ”， 并 将 其 从 节点 中 
进行 移 除 。 

































































8.1 DataNode 引 用 计数 磁盘 选择 策略 








DataNode 引 用 计数 磁盘 选择 策略 是 一 种 基于 引用 计数 值 作 为 衡量 指标 的 磁盘 选择 策略 。 这 里 的 “引用 计数 ” 指 的 是 当前 磁盘 被 引用 的 计数 ， 意 思 是 指 当前 磁盘 进行 读 写 操作 的 次 数 。 磁 盘 引用 计数 很 
高 表明 此 盘 目 前 正在 被 大 量 地 读 写 。 所 以 在 一 定 程度 上 而 言 ， 磁 盘 引 用 计数 策略 考虑 的 因素 在 于 磁盘 1O 的 负载 而 非 磁盘 间 的 数据 平衡 情况 。 此 策略 类 在 目前 HDFs 中 并 不 存在 ， 是 笔者 自 定义 的 一 个 策略 
类 。 所 以 在 本 节 内 容 的 讲述 中 ， 笔 者 将 会 详细 地 讲述 此 策略 类 与 现 有 策略 类 的 异同 以 及 它们 各 自 适 用 的 场景 。 
















































































8.1.1 HDFS 现 有 磁盘 选择 策略 


随 着 节点 数 的 扩 增 ， 集 群 中 的 总 磁盘 数 也 会 跟着 线性 变化 ， 这 么 多 块 磁盘 ， 会 造成 一 个 问题 : 数据 不 平衡 现象 。 这 是 很 容易 发 生 的 ， 原 因 有 以 下 2 点 : 








1) HDFS 写 操作 不 当 导 致 。 








2) 新 老 机 器 上 线 使 用 时 间 不 同 ， 造 成 新 机 器 数据 少 ， 老 机 器 数据 多 的 问题 。 























第 二 点 通过 Balancer 操 作 可 以 解决 ， 第 一 个 问题 才 是 最 根本 的 。 为 了 解决 磁盘 数据 空间 不 均衡 的 问题 ，HDFS 目 前 的 两 套 磁盘 选择 策略 都 是 围绕 着 “数据 平衡 ”的 目标 设计 的 。 下 面 主要 介绍 这 2 个 磁盘 
选择 策略 。 














1.RoundRobinVolumeChoosingPolicy 


标题 所 示 的 类 名 称 可 以 拆 成 2 个 单词 : RoundRobin 和 VolumeChoosingPolicy。Volume-ChoosingPolicy 理 解 为 磁盘 选择 策略 ，RoundRobin 则 是 一 个 专业 术语 ， 叫 做 “ 轮 询 ”。 类 似 的 还 有 一 些 别 的 
术语 : Round-Robin Scheduling ( 轮 询 调度 ) 、Round-Robin 算 法 等 等 。 一 句 话 来 概括 “ 轮 询 ”的 意思 : 一 个 一 个 地 去 遍历 ， 到 尾部 了 ， 再 从 头 开始 。 图 8-1 为 轮 询 算 法 原理 。 























Requester 





Selected 





Target1 Target2 





图 8-1 RoundRobin 原 理 图 


给 出 此 策略 的 核心 代码 ， 如 下 所 示 : 





// 轮 询 方式 的 磁盘 选择 策略 类 
public class RoundRobinVolumeChoosingPolicy<V extends FsVolumeSpi> 
implements VolumeChoosingPolicy<V> { 
public static final Log LOG = LogFactory.getLog (RoundRobinVolumeChoosingPolicy.class); 


private int curVolume = 0; 


QOverride 
public synchronized V chooseVolume (final List<V> volumes, long blockSize) 
throws IOException { 


// 如 果 磁 盘 数 目 小 于 1 个 ， 网 的 时 和 
if(volumes.size() < 1) 

throw new De more available volumes"); 
} 


// 如 果 由 于 失败 磁盘 导致 当前 磁盘 下 标 越界 了 ， 则 将 下 标 置 为 0 
if(curVolume >= volumes.size()) { 

curVolume = 07 
} 


// 起 始 下 标 赋值 
int startVolume = curVolume; 
long maxAvailable = 0; 


while (true) 

// 区 且 各 二 标 所 代表 的 磁盘 

final V volume = volumes.get (curVolume); 

// 下 标 递增 

curVolume = (curVolume + 1) % volumes.size(); 

2 关于 和 放生 家 的 半 且 测 个 

8 availableVolumeSize = volume .getAvailable(); 
/加 果 后 用 空间 注 足 所 和 要 的 本 本 娱 大 小 ， 则 直 捞 返 四 这 所 

作 (availableVolumeSize > blockSize) { 
return volume; 


} 

// 更 新 最 大 可 用 空间 值 

if (availableVolumeSize > maxAvailable) { 
maxAvailable = availableVolumeSize; 





} 


// 如 果 当 前 指标 又 回 到 了 起 始 下 标 位 置 ， 说 明 已 经 遍历 完整 个 磁盘 列表 
// 没有 找到 符合 可 用 空间 要 求 的 磁盘 


if (curVolume 一 startVolume) { 
throw new DiskOutOfSpaceException("Out of space: " 
+ "The volume with the most available space (=" + maxAvailable 
+ " B) is less than the block size (=" + blockSize + " B)."); 





理论 上 来 说 这 种 策略 是 比较 符合 数据 平衡 的 目标 的 ， 因 为 一 个 个 地 写 每 块 盘 ， 写 入 的 次 数 都 差不多 ， 不 存在 哪 块 盘 多 写 少 写 的 现象 。 但 是 唯一 的 不 足 之 处 在 于 每 次 写 入 的 数据 量 是 无 法 控制 的 。 可 能 
某 次 操作 在 A 盘 上 写 入 了 512 字 节 的 数据 ， 在 轮 到 B 盘 写 的 时 候 我 写 了 128MB 的 数据 ， 数 据 就 不 均衡 了 。 所 以 说 轮 询 策略 在 某 种 程度 上 来 说 是 理论 上 均衡 ， 但 还 不 是 最 好 的 ， 更 好 的 是 下 面 介绍 的 策略 。 











2.AvailableSpaceVolumeChoosingPolicy 


剩余 可 用 空间 磁盘 选择 策略 。 这 个 磁盘 选择 策略 比 第 一 种 策略 就 精妙 很 多 了 。 首 先 它 根据 一 个 阅 值 ， 将 所 有 的 磁盘 分 为 了 两 大 类 : 高 可 用 空间 磁盘 列表 和 低 可 用 空间 磁盘 列表 。 然 后 通过 一 个 随机 数 概 














率 ， 会 以 比较 高 的 概率 选择 高 剩余 空间 磁盘 列表 中 的 磁盘 ， 然 后 对 这 些 磁 盘 列 表 使 用 轮 询 策略 进行 选择 ， 下 面 是 相关 代码 : 

















// 根据 剩余 可 用 空间 进行 优先 选择 的 磁盘 选择 策略 类 
public class AvailableSpaceVolumeChoosingPolicy<V extends FsVolumeSpi> 
implements VolumeChoosingPolicy<V>, Configurable { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
a 用 和 般 的 需要 平衡 磁盘 的 轮 询 磁盘 选择 策略 
private final VolumeChoosingPolicy<V> roundRobinPolicyBalanced = 
new RoundRobinVolumeChoosingPolicy<V>(); 
// 用 于 可 用 空间 高 的 磁盘 的 轮 询 磁盘 选择 策略 
private final VolumeChoosingPolicy<V> roundRobinPolicyHighAvailable = 
new RoundRobinVolumeChoosingPolicy<V> (); 
// 用 字 可 用 空间 低 的 磁 禾 的 轮 询 碰 盘 迁 娠 策 路 
private final eb roundRobinPolicyLowAvailable = 
new RoundRobinVolumeChoosingPolicy<V> (); 





@Override 
public synchronized V chooseVolume (List<V> volumes, 
long replicaSize) throws IOException { 
if (volumes.size() < 1) { 
throw new DiskOutOfSpaceException ("No more available volumes"); 
} 


// 获取 所 有 磁盘 包装 列表 对 象 
AvailableSpaceVolumeList volumesWithSpaces = 
new AvailableSpaceVolumeList (volumes); 


// 如 果 所 有 的 磁盘 在 数据 平衡 阔 值 之 内 ， 则 在 所 有 的 磁盘 块 中 直接 进行 轮 询 选择 

if (volumesWithSpaces.areAllVolumesWithinFreeSpaceThreshold()) { 
V volume = roundRobinPolicyBalanced.chooseVolume (volumes, replicaSize); 
if (LOG.isDebugEnabled()) { 

LOG.debug ("All volumes are within the configured free space balance "+ 
"threshold. Selecting " + volume + " for write of block size " 十 
replicaSize); 

} 
return volume; 
} else { 
V volume = null; 
// 如 果 存在 数据 不 平衡 的 现象 ， 则 从 低 剩余 空间 磁盘 块 中 选 出 可 用 空间 最 大 值 
long mostAvailableAmongLowVolumes = volumesWithSpaces 
.getMostAvailableSpaceAmongVolumesWithLowAvailableSpace () 7 


// 得 到 高 可 用 空间 磁盘 列表 

List<V> highAvailableVolumes = extractVolumesFromPairs ( 
volumesWithSpaces.getVolumesWithHighAvailableSpace()); 

// 得 到 低 可 用 空间 磁盘 列表 

List<V> lowAvailableVolumes = extractVolumesFromPairs ( 
volumesWithSpaces.getVolumesWithLowAvailableSpace ()); 





float preferencePercentScaler = 
(highAvailableVolumes.size() * balancedPreferencePercent) + 
(lowAvailableVolumes.size() * (1 - balancedPreferencePercent)); 
// 计算 平衡 比值 ，balancedPreferencePercent 越 大 ，highAvailableVolumes.size() 所 占 的 比重 会 变 大 
// 整个 比例 值 也 会 变 大 ， 就 会 有 更 高 的 随机 概率 在 这 个 值 下 
float scaledPreferencePercent = 
(highAvailableVolumes.size() * balancedPreferencePercent) / 
preferencePercentScaler; 
// 如 果 低 可 用 空间 磁盘 列表 中 最 大 的 可 用 空间 无 法 满足 副本 大 小 
// 或 随机 概率 小 于 比例 值 ， 就 在 高 可 用 空间 磁盘 中 进行 轮 询 调度 选择 
if (mostAvailableAmongLowVolumes < replicaSize || 
random.nextFloat () < scaledPreferencePercent) { 
Volume = roundRobinPolicyHighAvailable.chooseVolume( 
highAvailableVolumes, replicaSize); 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Volumes are imbalanced. Selecting "+ volume + 
" from high available space volumes for write of block size 
+ replicaSize); 





} 
} 0 
寄 由 在 低语 航空 间 列 表 中 选择 磁盘 
6 = roundRobinPolicyLowAvailable.chooseVolume( 
lowAvailableVolumes, replicaSize); 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Volumes are imbalanced. Selecting " + volume + 
" from low available space Volumes for write of block size 
+ replicaSize); 


} 
. 


return volume; 





低 剩余 空间 磁盘 和 高 剩余 空间 磁盘 的 标准 是 这 样 定义 的 : 





// 获取 低 剩余 空间 磁盘 列表 
public List<AvailableSpaceVolumePair> getVolumesWithLowAvailableSpace() { 
long leastAvailable = 9 thoes bay Hespace (); 
List<AvailableSpaceVolumePair> ret = new ea ee 
for (AvailableSpaceVolumePair Vl ie volumes) 
By ET A 
// 则 将 此 磁盘 加 入 低 磁 盘 空 间 列 表 中 
if (volume.getAvailable() <= leastAvailable + balancedSpaceThreshold) { 
ret .add (volume); 
} 
} 
return ret; 


} 


// 获取 高 剩余 空间 列表 
public List<AvailableSpaceVolumePair> getVolumesWithHighAvailableSpace() { 
long leastAvailable = getLeastAvailableSpace(); 
List<AvailableSpaceVolumePair> ret = new ArrayList<AvailableSpaceVolumePair>(); 
for (AvailableSpaceVolumePair volume : volumes) { 
// 高 剩余 空间 磁盘 选择 条 件 与 上 面相 反 
if (volume.getAvailable() > leastAvailable + balancedSpaceThreshold) { 
ret .add (volume); 
} 
} 
return ret; 


} 





























到 此 我 们 已 经 了 解 了 HDFS 目 前 现 有 的 两 种 磁盘 选择 策略 。 那 么 HDFS 在 使 用 这 些 策略 上 到 底 是 不 是 完美 的 呢 ? 答案 显然 不 是 。 下 面 是 笔者 总 结 出 的 两 点 不 足 之 处 : 




















“ HDFS 黑 认 的 磁盘 选择 策略 是 RoundRobinVolumeChoosingPolicy， 而 不 是 更 优 的 AvailableSpaceVolumeChoosingPolicy。 笔 者 猜测 的 原因 是 AvailableSpaceVolumeChoosingPolicy 是 后 来 才 有 的 ， 但 是 默认 值 的 
选择 没有 改 ， 依 然 是 老 的 策略 。 但 同时 也 需要 指出 AvailableSpaceVolumeChoosingPolicy 策 略 可 能 存在 性 能 问题 。 一 旦 某 个 节点 新 添加 了 若干 块 新 磁盘 ， 按 照 它 的 策略 ， 大 部 分 的 数据 将 会 被 写 入 到 这 些 新 盘 
上 。 大 量 的 数据 同时 写 入 磁盘 会 造成 不 小 的 性 能 影响 。 


: 磁盘 选择 策略 考虑 的 因素 过 于 单一 。 磁 盘 可 用 空间 只 是 其 中 一 个 因素 ， 其 实 还 有 别 的 指标 也 值得 参考 ， 比 如 当前 磁盘 的 IO 情 况 。 当 我 们 准备 写 数据 到 磁盘 的 时 候 ， 我 们 当然 希望 找 一 些 闲置 的 磁盘 进 
于 数据 的 写 入 。 对 于 繁忙 的 磁盘 而 言 ， 这 只 会 更 加 影响 它 的 写 入 速度 。 此 因素 也 是 下 面 笔 者 自 定义 的 新 磁盘 选择 策略 的 一 个 根本 需求 点 。 


8.1.2 ” 自 定义 磁盘 选择 策略 























寻找 自 定义 磁盘 选择 策略 的 根本 依赖 点 在 于 ReferenceCount (引用 计数 ) ， 它 能 让 你 知道 有 多 少 对 象 正 在 操作 当前 磁盘 。 引 用 计数 的 原理 在 很 多 地 方 都 有 用 到 ， 比 如 JVM 中 通过 对 象 是 否 还 有 外 部 引 
来 判断 是 否 能 够 进行 垃圾 回收 。 在 磁盘 相关 类 FsVolume 中 恰好 有 一 个 引用 计数 相关 的 变量 ， 如 下 : 
























































public class FsVolumeImpl implements FsVolumeSpi { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
private CloseableReferenceCount reference = new CloseableReferenceCount () 7 














这 里 我 们 需要 将 此 变量 值 开放 出 去 ， 便 于 我 们 的 调 














// 获取 当前 磁盘 的 引用 计数 
public int getReferenceCount () { 
return this.reference.getReferenceCount () 7 





然后 模仿 AvailablespaceVolumeChoosingPolicy 策 略 进行 选择 ， 核 心 代 码 如 下 : 





QOverride 
Public synchronized V chooseVolume (final List<V> volumes, long blockSize) 
throws IOException { 


if (volumes.size() < 1) { 
throw new DiskOutOfSpaceException ("No more available volumes"); 


} 
V volume = null; 


// 获取 当前 磁盘 中 引用 次 数 最 少 的 一 块 盘 
int minReferenceCount = getMinReferenceCountOfVolumes (volumes); 
// 根据 最 少 引 用 次 数 以 及 引用 计数 临界 值得 到 低 引用 计数 磁盘 列表 
List<V> lowReferencesVolumes = 
getLowReferencesCountVolume (volumes, minReferenceCount); 
// 根据 最 少 引 用 次 数 以 及 引用 计数 临界 值得 到 高 引用 计数 磁盘 列表 
List<V> highReferencesVolumes = 
getHighReferencesCountVolume (volumes, minReferenceCount); 


// 判断 低 引 用 磁盘 列表 中 是 否 存在 满足 要 求 块 大 小 的 磁盘 ， 如 果 有 ， 优 先 从 低 引 用 计数 磁盘 中 进行 轮 询 磁盘 的 选择 

if (isExistVolumeHasFreeSpaceForBlock (lowReferencesVolumes, blockSize)) { 

Volume = 
roundRobinPolicyLowReferences.chooseVolume (lowReferencesVolumes, 
blockSize); 

到 下 
//_ 如 果 低 引用 计数 磁盘 块 中 没有 可 用 空间 的 块 ， 则 再 从 高 引用 计数 的 磁盘 列表 中 进行 磁盘 的 选择 
volume = 

FoundRobinPolicyHighReferences ,chooseVolume (highReferencesVolumes, 
blockSize) 7 





} 


return volume; 








附 上 相应 的 单元 测试 ， 测 试 已 经 通过 。 大 家 可 以 自行 在 自己 的 环境 中 进行 测试 。 





// 引用 计数 磁盘 选择 策略 模拟 测试 
QTest 
public void testReferenceCountVolumeChoosingPolicy() throws Exception { 
@SuppressWarnings ("unchecked") 
final ReferenceCountVolumeChoosingPolicy<FsVolumeSpi> policy = 
ReflectionUtils.newInstance (ReferenceCountVolumeChoosingPolicy.class, 
null); 
// 初始 化 引用 计数 磁盘 选择 策略 
initPolicy (policy); 
final List<FsVolumeSpi> volumes = new ArrayList<FsVolumeSpi>(); 


// 增加 2 块 低 引用 计数 的 磁盘 
// 第 一 块 盘 ， 只 被 引用 了 1 次 的 磁盘 
Volumes .add (Mockito.mock (FsVolumeSpi.class) ) 
Mockito.when (Volumes .get (0) .getReferenceCount () ) .thenReturn (1) 7 
Mockito.when (volumes.get(0) .getAvailable()) .thenReturn (100L) ， 


// 第 二 块 盘 ， 被 引用 了 2 次 的 磁盘 

Volumes .add (Mockito.mock (FsVolumeSpi .class)); 

Mockito.when (volumes .get (1) .getReferenceCount () ) .thenReturn (2); 
Mockito.when (volumes .get (1) .getAvailable()) .thenReturn (100L); 


// 增加 2 块 高 引用 计数 的 磁盘 

// 第 三 块 盘 ， 被 引用 了 4 次 的 磁盘 

Volumes .add (Mockito.mock (FsVolumeSpi.class) ) 

Mockito.when (volumes.get (2) .getReferenceCount () ) .thenReturn (4) 7 
Mockito.when (volumes .get (2) .getaAvailable () ) .thenReturn (100L) ， 


// 第 四 块 盘 ， 被 引用 了 5 次 的 磁盘 

Volumes .add (Mockito.mock (FsVolumeSpi .class)); 

Mockito.when (volumes .get (3) .getReferenceCount () ) .thenReturn (5); 
Mockito.when (volumes .get (3) .getAvailable()) .thenReturn (100L); 


// 用 引用 计数 磁盘 选择 策略 选择 一 个 可 用 空间 至 少 50 字 节 以 上 的 盘 ， 
// 于 是 将 会 选中 第 一 块 盘 ， 因 为 引用 次 数 少 ， 而 且 可 用 空间 满足 条 件 


Assert .assertEquals (volumes.get (0), policy.chooseVolume (volumes, 50)); 





Volumes.clear (); 
// 下 面 测试 的 场景 是 当 低 引用 计数 的 磁盘 可 用 空间 不 足 的 情况 


// 增加 第 一 块 盘 ， 引 用 计数 1， 可 用 空间 50 字 节 

Volumes .add (Mockito.mock (FsVolumeSpi.class) ) 

Mockito.when (volumes.get (0) .getReferenceCount () ) .thenReturn (1) 7 
Mockito.when (volumes.get (0) .getaAvailable () ) .thenReturn (50L) 7 


// 增加 第 二 块 盘 ， 引 用 计数 2， 可 用 空间 50 字 节 

Volumes .add (Mockito.mock (FsVolumeSpi .class)); 

Mockito.when (volumes .get (1) .getReferenceCount () ) .thenReturn (2); 
Mockito.when (volumes .get (1) .getAvailable()) .thenReturn (50L) 7 


// 增加 第 三 块 盘 ， 引 用 计数 4， 可 用 空间 200 字 节 

Volumes .add (Mockito.mock (FsVolumeSpi.class) ) 

Mockito.when (Volumes .get (2) .getReferenceCount () ) .thenReturn (4) 
Mockito.when (volumes.get (2) .getAvailable()) .thenReturn (200L) ， 


// 增加 第 三 块 盘 ， 引 用 计数 5， 可 用 空间 200 字 节 

Volumes .add (Mockito.mock (FsVolumeSpi .class)); 

Mockito.when (volumes .get (3) .getReferenceCount () ) .thenReturn (5); 
Mockito.when (volumes .get (3) .getAvailable()) .thenReturn (200L); 


// 用 引用 计数 磁盘 选择 策略 选择 一 个 可 用 空间 至 少 在 100 字 节 以 上 的 盘 ， 
ht 2 引用 计数 少 ， 但 是 其 可 用 空间 不 足 ， 退 而 求 其 次 ， 只 能 选择 
Assert .asserthquals (volumes .get (2), policy.chooseVolume (volumes, 100)); 


























} 
































当然 引用 计数 磁盘 选择 策略 也 不 见得 是 最 好 的 ， 因 为 这 里 忽略 了 磁盘 间 数 据 不 平衡 的 问题 。 这 个 次 端 会 慢 慢 凸显 出 来 ， 所 以 说 很 难 有 一 个 策略 是 绝对 完美 的 。 最 好 的 办 法 是 根据 用 户 使 用 场景 使 用 最 合 
适 的 磁盘 选择 策略 ， 比 如 定期 更 换 策略 以 此 达到 最 佳 的 效果 。 引 用 计数 磁盘 选择 策略 的 相关 代码 可 以 从 下 面 笔者 的 GitHub 链 接 中 查阅 、 学 习 ， 链 接 如 下 : https://github.com/linyiqun/open-source- 



























































patch/blob/master/hdfs/others/HDFS-volume-ChoosingPolicy/HDFS-001.patch。 


8.2 ”Hadoop 节 点 “ 慢 磁 盘 ” 监控 


Hadoop 节 点 “ 慢 磁盘 ”监控 源 自 于 笔者 工作 中 的 一 次 “ 慢 磁 盘 ”故障 处 理 ， 在 问题 的 解决 中 实现 了 “ 慢 磁盘 ”的 监控 。 这 里 的 “ 慢 磁盘 ” 指 的 是 写 入 数据 非常 慢 的 一 类 磁盘 。 其 实 慢 磁盘 并 不 少见 ， 
当 机 器 运行 时 间 长 了 ， 上 面 跑 的 任务 多 了 ， 磁 盘 的 读 写 性 能 自然 会 退化 ， 严 重 时 就 会 出 现 写 入 数据 延 时 的 问题 。 目 前 磁盘 监控 在 HDFs 中 并 没有 做 得 很 全 ， 大 多 数 都 是 对 DataNode 整 体 做 监控 ， 可 以 说 这 是 
一 个 讶 区。 本 节 将 完整 地 介绍 笔者 在 工作 中 解决 此 次 慢 磁 盘问 题 的 整个 过 程 ， 主 要 包括 慢 磁 盘 的 发 现 和 慢 磁 盘 的 监控 两 方面 内 容 。 











8.2.1 “” 慢 磁盘 的 定义 以 及 如 何 发 现 


在 这 里 笔者 暂且 用 “ 慢 磁 盘 ” 来 解释 这 个 现象 ， 英 文 描述 为 slow-writed disk， 译 为 写 入 操作 很 慢 的 磁盘 。 这 里 的 写 操作 主要 包括 创建 文件 、 目 录 ， 写 文件 数据 等 操作 。 而 慢 磁盘 指 的 是 写 操作 耗 时 远 
远 超 出 平均 时 间 的 一 类 磁盘 。 笔 者 在 工作 中 就 碰 到 了 这 样 的 场景 ， 其 他 正常 的 盘 基 本 上 创建 1 个 test 目 录 ， 只 需 1/10 或 者 快 的 1/100 秒 左右 的 时 间 。 而 笔者 惊奇 地 发 现 有 块 盘 竟 然 花 了 5 分 钟 左右 ， 更 奇怪 的 
是 ， 这 个 现象 会 时 不 时 地 出 现 ， 并 不 是 每 次 都 有 。 一 旦 出 现 了 慢 磁 盘 ， 将 会 严重 拖 慢 这 个 节点 的 整体 运行 效率 ， 继 而 让 此 节点 成 为 集群 中 的 慢 节点 ， 最 后 影响 整个 集群 。 那 么 问题 来 了 ， 既 然 慢 磁盘 这 么 寻 
要 ， 我 们 怎么 准确 定位 到 是 哪 台 机 器 的 哪 块 磁盘 有 问题 呢 ? 集群 中 包含 了 那么 多 个 节点 ， 每 个 节点 上 又 有 那么 多 块 盘 ， 一 个 个 地 去 找 绝对 不 是 一 个 合适 的 办 法 。 











on 


下 面 教 大 家 几 个 方法 来 发 现 慢 磁盘 : 





' 通过 心跳 未 联系 时 间 。 一 般 如 果 出 现 慢 磁 盘 现 象 ， 会 影响 到 DataNode 与 NameNode 之 间 的 心跳 ， 图 8-2 中 的 Last contact 值 会 持续 变 大 ， 这 个 值 为 此 DataNode 与 NameNode 之 间 目 前 失去 联系 的 时 间 (时 间 
按 秒 算 ) 。 正 常情 况 下 ，Last contact 值 应 小 于 3， 因 为 DataNode 心 跳 的 默认 发 送 间隔 是 3 秒 。 











Hadoop Overview Datanodes Datanode Volume Failures Snapshot Startup Progress Utilities 


Datanode Information 


In operation 


Last contact | Admin State ”Capacity Used Non DFS Used Remaining Blocks Biock poolused Failed Volumes Version 
2 In Service 98.31GB 30101MB 142GB 83.81 GB 590 301.01 MB (0.3%) 0 2.7.1 


图 8-2 ”DataNode 与 NameNode 的 心跳 未 联系 间隔 

















“ 通过 Ganglia 对 DataNode 写 操作 的 相关 监控 ， 这 个 是 传统 的 方式 ， 如 图 8-3 所 示 。 
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14;30 14:40 14:50 15:00 


由 
3 last hour Now: 0.66 


14:30 14:40 14:50 15:10 15:20 


last nour : 人 Min: 856,67m 
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对 比 几 个 特殊 的 节 
个 脚本 在 所 有 的 磁盘 上 执行 。 


点 ， 观 察 这 些 节 点 在 写 操作 时 间 上 有 没有 特别 长 的 ,使 


图 8-3 ”Ganglia 对 DataNode 写 操作 的 相关 监控 














这 种 方法 可 以 确定 可 疑 慢 磁 盘 所 在 的 节 


点 。 假 设 














节点 已 经 发 现 ， 可 以 使 





最 简单 的 方法 来 发 现 节 


点 上 的 慢 磁 盘 ， 即 写 一 





time mkdir test 
I = =~£ tnt 




















观察 哪个 磁盘 所 花 的 时 间 最 长 就 可 以 了 。 我 们 也 可 以 


8.2.2 ” 慢 磁 盘 监 控 








上 面 提供 的 方法 在 使 
入 时 间 的 监控 ， 接 下 来 我 们 要 











性 和 准确 性 方面 还 存在 许多 偏差 ， 尤 其 是 在 寻找 慢 磁盘 的 方法 上 。 
添加 自 定义 的 监控 统计 代码 。 下 面 简单 介绍 我 们 是 如 何 对 此 进行 改造 的 。 首 先 要 明白 











Linux 系 统 中 专门 检查 磁盘 读 写 性 能 的 命令 ， 





因此 最 可 靠 的 方法 还 是 在 Hadoop 层 


这 种 方式 会 更 加 准确 一 些 。 














四 


对 每 个 磁盘 进行 写 操作 的 时 间 监 控 ， 这 无 疑 是 最 准 的 。 

















一 定 的 逻辑 关系 ，DataNode 与 磁盘 对 应 的 关系 如 下 : 


为 要 做 磁盘 写 














DataNode-->FsDatasetImpl-->volumesList 





在 volumesList 里 包含 了 各 个 磁盘 上 的 数据 存储 目录 。 每 个 磁盘 对 应 的 类 是 FsVolumelmpl， 在 FsVolumelmpl 类 中 包含 了 许多 创建 文件 的 方法 。 























这 些 创建 的 文件 会 最 终 写 入 这 个 类 所 代表 的 磁盘 中 ， 因 此 我 们 要 监控 的 对 象 就 是 它 。 本 节 开 始 的 时 候 已 经 说 了 ，Hadoop 社 区 没有 对 FsVolume 做 额外 的 监控 ， 所 以 需要 我 们 自己 新 定义 一 个 Metric 类 ， 
这 里 暂且 叫做 FsVolumeMetrics， 内 部 指标 定义 如 下 : 
@Metrics (about = "FsVolume metrics", context = "dfs") 


public class FsVolumeMetrics { 
static final Log LOG = LogFactory.getLog (FsVo. 
Private static final Map<String, FsVolumeMetr 
Maps. newHashiiap ()y 
// Counter 在 这 里 只 是 为 了 测试 的 需要 ， 实 际 可 省 略 
int getTmpInputStreamsCounter; 
int createTmpFileCounter; 
int createRbwFileCounter; 
int getTmpInputStreamsTimeoutCounter; 


int createTmpFileTimeoutCounter; 
int createRbwFileTimeoutCounter; 
MetricsRegistry registry = null; 
// 写 磁盘 文件 的 耗 时 指标 

Q@Metric 

MutableRate getTmpInputStreamsOp; 
@Metric 

MutableRate createTmpFileOp; 
Q@Metric 


MutableRate createRbwFileOp; 


// 写 磁盘 文件 的 超时 记录 指标 

@Metric 

MutableRate getTmpInputStreamsTimeout; 
Q@Metric 

MutableRate createTmpFileTimeout; 
@Metric 

MutableRate createRbwFileTimeout; 


// 初始 化 磁盘 Metric 统 计 类 ， 将 各 个 计数 值 置 为 0 
private FsVolumeMetrics (FsVolumeImpl volume) 
this.createRbwFileCounter = 0; 
this.createTmpFileCounter = 0; 
this.getTmpInputStreamsCounter = 
this.createRbwFileTimeoutCounter 

this.createTmpFileTimeoutCounter = 0; 
this.getTmpInputStreamsTimeoutCounter = 0; 





String name = "fsVolume:" + volume.getBaseP: 


LOG.info ("Register fsVolumn metric for path: 


registry = 


» 


new MetricsRegistry (name); 


http 
// RA OR 后 续 方 

public void addCreateTmpFileOp (long time) { 
createTmpFileCountert++; 
createTmpFileOp.add (time); 

} 


public void addCreateTmpFileTimeout (long time 


lumeMetrics.class); 
ics> REGISTRY = 


ath (); 
"+ name); 


法 同 理 


ee! 


/Www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 


Public void addCreateRbwFileOp (long time) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 


public void addCreateRbwFileTimeout (long time 


) 1 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 














为 对 每 个 磁盘 都 需要 有 各 自 的 监控 ， 所 以 在 注册 名 称 的 时 候 得 带 上 路 径 以 做 区 分 。 





的 超时 情况 也 统计 一 遍 。 所 以 这 里 要 新 定义 一 个 写 磁 盘 的 超时 时 间 ， 如 下 所 示 : 


在 FsVolumeMetrics 统 计 类 中 使 

















MutableRate 类 的 好 处 是 可 以 同时 监控 到 次 数 和 时 间 ， 


然后 对 应 地 把 这 些 写 操作 





public static final String DFS WRITE VOPUME THRESHOLD TIME MS = 


"dfs.write.volume.threshold.time.ms"; 
public static final long DFS_WRITE VOLUME THRES 


HOLD TIME MS DEFAULT = 300; 





接 下 来 是 注册 此 Metric 类 代码 ， 注 意 这 需要 在 FsVolu 


melmpl 类 中 注册 : 





FsVolumeImpl (FsDatasetImp1 dataset, String stor. 
Configuration conf, StorageType storageType 
this.dataset = dataset; 
this.storageID = storagelID; 
this.reserved = conf.getLong( 
DFSConfigKeys.DFS DATANODE DU RESERVED KE 
DFSConfigKeys . DFS 1 DATANODE DU :1 RESERVED | DE 
this.reservedForRbw = new AtomicLong (0L); 


ageID, File currentDir, 
) throws IOException { 


YY 
FAULT) ; 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. .http://www.hzcourse.com/resource/readBook?path=/openresources/teach 


// 在 FsVolumeImp1 构 造 方 法 中 进行 Metric 类 的 初始 化 
metric = FsVolumeMetrics.create (this); 





这 样 每 个 磁盘 就 会 有 各 自 的 监控 类 了 。 然后 进行 写 操作 耗 时 的 监控 ， 











给 出 对 其 中 createRbw 方 法 的 监控 ， 其 余 方法 类 似 ， 就 不 列举 了 ， 在 本 节 末尾 会 给 


出 代码 链接 。 





Override // FsDatasetSpi 
public synchronized ReplicaHandler createRbw( 
StorageType storageType, ExtendedBlock b, boolean allowLazyPersist) 
throws IOException { 
ReplicaInfo replicaInfo = volumeMap.get (b.getBlockPoolId(), 
b.getBlockId()); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/..http://www.hzcourse.com/resource/readBook?path=/openresources/teac 


} 
FsVolumeImpl v = (FsVolumeImpl) ref.getVolume(); 
// create an rbw file to hold block in the designated volume 
File f; 
trey 
// 进行 写 操作 前 后 时 间 记 录 
long startTime = Time.monotonicNow(); 
£f = V.CreateRbwFile (b.getBlockPoolId(), b.getLocalBlock()); 
long duration = Time.monotonicNow() - startTime; 
// 如 果 写 操作 时 间 超 出 阔 值 ， 则 进行 计数 递增 操作 
if (duration > volumeThresholdTime) { 
LOG.warn ("S1ow create RbwFile to volume=" + V.getBasePath () + " took " 
+ duration + "ms (threshold=" + volumeThresholdTime + "ms)"); 
V.metric.addCreateRbwFileTimeout (duration); 
于 
V.metric.addCreateRbwFileOp (duration) 7 
catch (IOException e) { 
IOUtils.cleanup (null, ref); 
throw e; 


} 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/..http://www.hzcourse.com/resource/readBook?path=/openresources/teac 
} 














代码 是 加 在 FsDatasetlImple 类 中 的 ， 因 为 方法 是 在 这 发 起 的 。 所 以 总 的 来 说 ， 监 控 处 理 的 代码 逻辑 其 实 并 不 复杂 。 了 既然 是 Hadoop 内 部 的 统计 监控 类 ， 它 能 够 直接 展示 在 Ganglia 的 界面 上 ， 见 图 8-4。 









































因为 笔者 配置 的 数据 目录 是 /home/data/data/hadoop/dfs/data， 所 以 图 8-4 中 会 出 现 上 面 那么 长 的 图 形 小 标题 。 图 8-4 就 是 我 们 想 要 达到 的 最 终 效果 ， 希 望 能 带 给 大 家 收获 。 此 功能 笔者 已 经 打 成 
patch， 提 交 开 源 社 区 ， 编 号 HDFS-9510。 要 使 用 此 功能 的 同学 可 以 自行 获取 代码 ，HDFS-9510 地 址 如 下 : 




















https://issues.apache.org/jira/browse/HDFS-9510。 











如 果 慢 磁 盘 已 经 发 现 了 ， 怎 么 解决 呢 ? 最 干脆 的 办 法 就 是 立即 下 线 ， 不 要 再 往 这 块 盘 上 写 数 据 了 ， 并 联系 运 维 部 门 进行 处 理 或 者 说 自己 内 部 想 办 法 解决 。 但 是 还 是 那 句 话 ， 像 慢 磁 盘 这 样 的 偏 硬件 性 的 
问题 还 是 交 给 这 方面 专业 的 人 去 解决 比较 稳妥 。 








dfs.fsVolume:/home/data/data/hadoop/dfs/data metrics (12) 


dfs.fsVolume_%2Fhome%2Fdata%2Fdata%2Fhadoop%2Fdfs%2Fdata.CreateRbwFiieAvgTime dfs.fsVolume_%2Fhome%2Fdata%2Fdata%2Fhadoop%2Fdfs%2Fdata,CreateRbwFileNumOps 


ED Hide/Show Events Timeshit ED Hide/Show Events Timeshift 


.fsVvolume_ /home/data/data/hadoop/dfs/data.CreateRbwFileNu 
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fs.fsVolume_%2Fhomes%2Fdata9%2Fdata%oe2Fhadoopq%2Fdfs9%2Fdata.CreateRbwFileTimeoutAvgTime dfs.fsvolume_%2Fhome%2Fdata%b2Fdata%2Fhadoop%2Fdfs%2Fdata. CreateRbwFileTimeout NumOps 


ED Hide/Show Events = Timeshift ED Hide/Show Events Timeshift 


syolume_/home/data/data/hadoop/dfs/da ta, CreateRbwFileTimeoutA iSVolume_/home/data/data/hadoop/dfs/data .CreateRbwFileTimeoutN 
1.0 1.0 
0.8 0.8 
0.5 0.6 
0.4 0.4 
0.2 0.2 
0.0 0.0 





a/hadoop/dfs/data 





ta/hadoop/dfs/data 


局 16:00 16:10 16:20 16:30 16:40 16:50 16:00 16:10 16:20 16:30 16;40 
如 No matching metrics detected 3 No matching metrics detected 


fs.fsVolume_%2Fhomes%2Fdata%2Fdata%2Fhadoop%2Fdfs3%2Fdata.CreateTmpFlleAvgTime dfs.fsyvolume_%2Fhome%2Fdatas%2Fdata%2Fhadoop3e2Fdfs%2Fdata,CreateTmpFlleNumops 





图 8-4 ”Ganglia 的 FsVolume 写 磁盘 操作 监控 


83 小结 

















本 章 介绍 的 两 个 基于 磁盘 的 改造 更 多 的 是 一 种 创新 的 改造 ， 难 度 并 不 会 太 大 ， 大 家 只 需 理解 其 用 意 本 身 即 可 。 本 章 提出 的 “ 慢 磁 盘 ” 的 监控 还 是 比较 重要 的 ， 往 往 有 的 时 候 这 类 盘 会 拖 慢 一 个 节点 。 








第 9 章 HDFS 的 异常 场景 


本 章 将 为 大 家 介绍 几 个 笔者 在 工作 过 程 中 遇 到 的 HDFS 异 常 场景 以 及 解决 方法 。 首 先是 DataNode 的 慢 启动 问题 ，DataNode 启 动 在 有 的 时 候 需要 花费 接近 5 分 钟 的 时 间 。 其 次 是 Hadoop 节 点 在 中 止 下 
线 操作 后 ， 会 出 现 大 量 多 余 块 的 情况 。 最 后 是 HDFS 在 读 写 数据 时 发 生 的 线程 泄露 问题 ， 线 程 泄露 类 似 于 内 存 泄露 问题 ， 是 一 个 比较 严重 的 问题 。 





9.1 ”DataNode 慢 启动 问题 


正常 情况 下 ， 一 个 DataNode 启 动 的 速度 一 般 在 几 秒 或 者 十 几 秒 的 时 间 。 但 是 在 某 些 特殊 的 场合 下 ，DataNode 会 出 现 启动 长 达 几 分 钟 的 现象 ， 在 本 节 中 我 们 称 此 现象 为 “DataNode 慢 启动 ”。 
DataNode 的 慢 启动 不 会 导致 它 上 面 的 数据 发 生 丢 失 ， 但 是 它 会 影响 服务 的 恢复 。 假 设 集群 中 所 有 的 DataNode 都 出 现 了 长 达 4、5 分 钟 的 慢 启动 现象 ， 那 么 集群 对 外 提供 服务 的 时 间 就 会 受到 影响 。 本 节 将 
完整 地 讲述 DataNode 慢 启动 的 问题 ， 包 括 慢 启动 现象 的 发 现 、 慢 启动 的 原因 分 析 和 最 后 的 问题 解决 。 








9.1.1 _ DataNode 慢 启动 现象 


首先 看 到 这 个 小 标题 ， 可 能 有 人 会 有 疑问 : DataNode 还 会 出 现 慢 启动 现象 y DataNode 执 行 了 sbin/hadoop-daemon.sh start datanode 命 令 后 不 是 几 秒 钟 的 事情 吗 ? 这 当然 没有 错 ， 在 绝 大 多 数 的 


场景 下 ，DataNode 的 启动 就 是 简 生 





1) 停止 机 器 上 的 DataNode 服 务 。 


2) 将 此 节点 进行 机 





房 搬迁 ， 搬 迁 后 此 节点 将 会 拥有 新 的 3 








的 这 么 几 个 步骤 。 但 是 不 知道 大 家 有 没有 尝试 过 如 下 的 情况 : 


E 机 名 和 ip 地 址 。 


3) 在 第 二 步骤 的 搬迁 过 程 中 耗费 了 20、30 分 钟 甚至 长 达 数 小 时 。 








4) 重启 被 更 换 掉 











笔者 在 最 近 一 段 时 | 
完 脚本 之 后 ， 笔 者 发 现 NameNode 的 页 夯 
DataNode 的 日 志 中 也 4 





时 间 内 恢复 DataNode, 
看 它 的 输出 日 志 ， 看 看 DataNode 在 这 段 时 间 执 行 了 什么 操作 。 经 过 多 次 实验 ， 笔 者 发 现 DataNode 在 每 次 打 完 下 面 这 些 信息 的 时 候 ， 就 会 停留 相当 长 的 时 间 。 








上 现 了 块 的 接收 、 志 


机 名 、ip 地 址 的 DataNode。 























间 的 DataNode 迁 移 中 就 遇 到 了 上 述 的 场景 ( 感 兴趣 的 同学 可 以 查阅 第 7.4 节 DataNode 迁 移 方案 里 面 的 内 容 ) 。 在 笔者 启动 完 新 的 DataNode 之 后 ， 就 发 生 了 慢 启动 的 现象 。 在 执行 
上 迟 迟 没有 这 个 新 节点 汇报 上 来 的 块 总 数 信息 。 笔 者 用 jps 观 察 这 个 进程 也 的 确 还 是 在 的 ， 直 到 4、5 分 钟 之 后 ， 页 面 上 终于 出 现 了 DataNode 的 记录 信息 了 。 之 后 
除 记录 。 所 以 很 显然 DataNode 在 启动 的 这 4、5 分 钟 里 一 定 阻塞 在 了 什么 操作 上 ， 和 否则 不 会 出 现 这 么 长 时 间 的 延 时 。 王 万 不 要 小 看 了 这 4、5 分 钟 ， 当 你 需要 在 短 
肛 务 的 时 候 ， 哪 怕 你 多 耽搁 了 1 秒 钟 ， 影 响 了 别人 的 使 用 ， 人 家 还 是 会 认为 这 就 是 你 的 问题 。 既 然 目 标 已 经 锁定 在 DataNode 启 动 的 头 4、5 分 钟 ， 那 么 一 个 好 的 排查 问题 的 办 法 就 是 去 
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INFO 
INFO 
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INFO 
INFO 
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org. 
org. 


apache .hadoop.hdfs. 
apache .hadoop.hdfs. 
apache .hadoop.hdfs. 
apache .hadoop.hdfs. 
apache .hadoop.hdfs. 
apache .hadoop.hdfs. 


server.datanode.fsdataset.impl.FsDatasetImpl: Scanning block pool BP-1942012336-xx.xx.Xxx.xx-1406726500544 on volume /home/ds 
server .datanode.fsdataset.impl.FsDatasetImpl: Scanning block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on volume /home/da 
server.datanode.fsdataset.impl.FsDatasetImpl: Scanning block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on volume /home/ds 
server.datanode.fsdataset.impl .FsDatasetImpl: Time taken to scan block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on /home 
server .datanode.fsdataset.impl.FsDatasetImpl: Time taken to scan block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on /home 
server.datanode.fsdataset.impl.FsDatasetImpl: Time taken to scan block pool BP-1942012336-xx.xx.xx.xx-1406726500544 on /home 























我 们 可 以 从 日 志 中 看 到 ， 在 DataNode 添 加 完 磁盘 块 后 ， 进 行 扫描 操作 的 时 候 ， 从 16:05 分 直接 跳 到 了 16:09 的 记录 ， 就 是 在 最 后 一 次 Scanning block 的 那 行 。 显 然 就 是 这 段 时 间 导 致 的 DataNode 慢 启 
动 。 所 以 我 们 可 以 以 此 作为 关键 线索 ， 进 行 分 析 ， 一 个 有 效 的 办 法 是 通过 日 志 进 行 代码 追踪 分 析 。 


9.1.2 ”代码 追踪 分 析 




















通过 上 文 日 志 记 录 信 息 的 内 容 显示 ， 这 条 信息 是 FsDatasetImpl 中 的 Log 对 象 打出 的 ， 但 是 这 个 Log 对 象 其 实 是 在 男 外 一 个 叫 FsVolumeList 的 类 中 被 调用 的 ， 代 码 如 下 : 











void addBlockPool (final String bpid, final Configuration conf) throws IOException { 
long totalStartTime = Time.monotonicNow(); 


final List<IOException> exceptions = Collections.synchronizedList ( 

new ArrayList<IOException>()); 
List<Thread> blockPoolAddingThreads = new ArrayList<Thread> () 7 
volumes.get ()) { 


for (final FsVolumeImpl v : 


Thread 七 = new Thread () 


Public void run () 
try (FsVolumeReference ref = v.obtainReference()) { 
FsDatasetImpl .LOG.info("Scanning block Pool " + bpid + 


{ 


// 在 引入 新 磁盘 前 记录 起 始 时 间 


lon: 


// 执行 添加 动作 


startTime = Time.monotonicNow (); 


Vv.addBlockPool] (bpid, conf); 
// 记录 操作 结束 时 间 
long timeTaken = Time.monotonicNow() - startTime; 

FsDatasetImpl .LOG.info("Time taken to scan block pool " + bpid + 


on 


i 


" + timeTaken + "ms"); 
catch (ClosedChannelException e) { 


on Volume " + V + "http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/..."); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 
jy 


blockPoolAddingThreads .add (t); 


t.start () 7 


for (Thread 七 : 


2 
// 调用 join 方 法 等 待 此 线程 运行 结束 


tr 


t.join(); 
} catch (InterruptedException ie) { 
throw new IOException (ie); 


} 
} 


blockPoolAddingThreads) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


在 添加 每 块 盘 上 的 BlockPool 操 作 的 时 候 ， 是 采 














创建 线程 的 方式 ， 并 且 调 用 了 join 方法 等 待 线程 结束 。 我 们 再 查看 : 


























中 的 操作 来 看 看 到 底 是 在 干什么 ， 首 先 查看 下 面 的 这 个 方法 : 

















void addBlockPool (String bpid, Configuration conf) throws IOException { 
File bpdir = new File(currentDir, bpid); 
// 新 建 BlockPoolS1ice 对 象 
BlockPoolSlice bp = new BlockPoolSlice (bpid, this, bpdir, conf); 
bpSlices.put (bpid, bp); 


} 





BlockPoolSlice 又 是 什么 类 呢 ， 其 源码 上 的 注释 介绍 如 下 : 





// 一 个 BlockPoolS1ice 代 表 一 个 BlockPool 存 在 于 一 块 磁盘 上 的 一 部 分 ， 所 有 同属 一 个 
// BlockPool id 下 的 BlockPoolS1ice 构 成 了 整个 BlockPool。 
class BlockPoolSlice { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


注释 大 意 为 BlockPoolSlice 是 一 个 BlockPool 存 储 在 每 块 盘 上 的 一 部 分 。 比 如 我 们 有 3 块 盘 A、B、C,， 每 个 盘 下 都 有 对 应 目录 来 存放 此 BlockPool id 对 应 的 数据 。BlockPool id 又 是 哪里 确定 的 呢 ? 这 里 
要 单独 介绍 这 方面 的 知识 。 




















DataNode 与 FsVolume 磁 盘 的 相关 逻辑 关系 为 : 首先 是 BlockPool id， 这 个 id 是 在 集群 第 一 次 开始 创建 的 时 候 确定 的 ， 就 是 在 NameNode 做 format 操 作 的 时 候 。 不 管 在 后 续 的 集群 升级 或 者 搬迁 的 过 
程 中 ， 这 个 id 都 不 会 发 生 改 变 。 此 id 信息 保存 在 了 Namespacelnfo 这 个 类 中 ， 下 面 是 这 个 类 的 介绍 说 明 : 























// NamespaceInfo 信 息 在 NameNode 与 DataNode 担 手 通信 的 时 候 将 被 返回 
Public class NamespaceInfo extends StorageInfo { 


final String buildqVersiony 


// BlockPool 了 唯一 id 
String blockPoolID = ""; 
String softwareVersion; 
long capabilities; 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 








DataNode 与 FsVolume 的 关系 结构 见 图 9-1。 











回 到 本 节 所 讨论 的 慢 启动 问题 ， 这 些 操作 目前 看 起 来 并 不 耗 时 。 我 们 继续 往 里 看 ， 进 入 BlockPoolslice 的 构造 方法 : 





BlockPoolSlice (String bpid, FsVolumeImpl volume, File bpDir, 

Configuration conf) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// 靳 起 DO 操作 对 象 用 米 加 载 DEsUsed 针 ， 如 果 DfsUsed 缓 在 值 个 生效 ， 

// 则 会 阻塞 地 执行 Gu 命令 直到 此 操作 的 完成 
this.dfsUsage = new DU (bpDir, conf, loadDfsUsed()); 
this.dfsUsage.start (); 


// 如 果 进 程 突然 停止 ， 保 证 DfsUsed 值 还 是 能 被 保存 下 来 
ShutdownHookManager .get () .addShutdownHook ( 
new Runnable() { 
QOverride 
public void run() { 
if (!dfsUsedSaved) { 
saveDfsUsed (); 
} 


. 
}, SHUTDOWN HOOK PRIORITY); 
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FsVolume2 
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9-1 DataNode 与 FsVolume 逻 辑 关 系 图 





























终于 在 这 里 我 们 找到 了 关键 操作 ， 在 构造 函数 中 会 进行 1 次 du (统计 数据 使 用 量 ) 操作 。 同 时 注释 中 特意 说 明 ， 如 果 DfsUsed 缓 存 值 不 可 用 的 话 ， 会 进行 du 命令 操作 ， 阻 塞 后 续 操作 直到 du 操作 完成 。 
那 基本 我 们 可 以 判断 出 DataNode “ 慢 启动 ”场景 属于 缓存 值 失效 的 情况 ， 加 载 DfsUsed 缓 存 值 的 方法 是 loadDfsUsed， 进 入 此 方法 : 











long loadDfsUsed() { 
long cachedDfsUsed; 
long mtime; 
Scanner sc; 


try { 
// 初始 化 文件 扫描 对 象 
sc = new Scanner (new File (CurrentDir，DU_CRACHE FILE), “UTF-8"); 
} catch (FileNotFoundException fnfe) { 
return -=1} 


try 
7 《光电 这 个 文件 中 人 个 入 
if (sc.hasNextLong () ) 
// 从 交 说 呈 区 联 Ed 组 在 值 
cachedDfsUsed = sc.nextLong () 7 
} else { 
return -1; 


7/ 判断 这 个 文件 中 i 个 值 
if (sc.hasNextLong () ) 
// 获取 文件 中 的 上 潜 遇 录 时 间 
mtime = sc.nextLong () 7 
} else { 
return -1; 


// 如 果 上 次 记录 时 间 与 当前 时 间 的 差 值 不 超过 10 分 钟 ， 则 可 以 直接 返回 上 次 的 缓存 值 


否则 将 


(mtime > 0 && 


会 返回 -1， 从 而 导致 DataNode 重 新 对 此 盘 进 行 Gu 计算 


让 (Time.now() - mtime < 600000L)) { 


FsDatasetImpl .LOG.info("Cached dfsUsed found for " + currentDir + ": "+ 


cachedDfsUsed); 
return cachedDfsUsed; 
return -1; 
} finally { 
sc.close(); 





在 这 里 


， 会 首先 从 传 入 的 目录 地 址 中 读 取 缓存 值 文件 ， 如 果 更 新 时 间 在 600 秒 以 内 ， 则 直接 读 取 该 值 ， 否 则 返 




















， 然 后 重新 进行 du 计算 。 因 为 笔者 的 使 用 场景 ， 使 DataNode 停 止 服务 的 时 间 超 过 了 















































30 分 钟 或 者 更 久 ， 导 致 更 新 此 缓存 文件 的 间隔 时 间 超过 了 600 秒 ， 缓 存 文件 将 直接 失效 ， 后 





的 du 操作 自然 就 发 生 了 。 到 了 这 里 问题 基本 锁定 了 ， 就 是 在 这 个 写 死 的 600 秒 上 。 专 业 上 的 术语 叫做 “hard 
































code”， 对 于 一 些 标准 的 变量 ,这 是 


9.1.3 ”参数 可 配置 化 改造 











现在 目标 已 经 非常 明确 了 ， 就 是 将 硬 编 码 值 变 成 可 配置 化 的 值 ， 将 此 配置 作为 hdfs-site.xml 的 一 个 新 配置 项 


不 合理 的 ， 我 们 要 将 其 可 配置 化 ， 来 适应 使 用 者 的 需求 。 














至 少 在 笔者 的 使 用 情况 下 ， 我 根本 不 需要 进行 DfsUsed 值 的 再 计算 ， 因 为 DataNode 上 面 的 数据 没有 经 过 任何 











回 


简要 说 明 改 造 的 步 又， 首先 在 DfsConfigKeys 类 里 添加 key 名 称 和 默认 值 : 














public static final String DFS DATANODE CACHED DFSUSED CHECK INTERVAL MS = 


"dfs.datanode.cached-dfsused.check.interval .ms"; 


public static final long DFS DATANODE CACHED DFSUSED CHECK INTERVAL DEFAULT MS = 


600000; 





在 BlockPoolSlice 中 新 增 变量 ， 








并 获取 此 新 配置 项 属性 ， 如 果 没 有 设置 ， 则 取 默 认 值 : 





class BlockPoolSlice { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


Private final long cachedDfsUsedCheckTime; 


// 在 Federation 使 用 场景 下 的 扩展 问题 ， 
private final DU dfsUsage; 


BlockPoolSlice (String bpid, FsVolumeImpl volume, File bpDir, 
Configuration conf) throws IOException { 


每 个 BlockPoolS1ic 一 个 DU 线程 ， 会 造成 DU 线程 过 


多 的 问题 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 


// 获取 新 配置 中 的 缓存 检测 时 间 
this, Ce de = 
conf.getLong( 


DFSConfigKeys.DFS DATANODE CACHED DFSUSED CHECK INTERVAL MS, 
DFSConfigKeys . DFS 1 DATANODE ”CACHED 1 DFSUSED CHECK INTERVAL ] DEFAULT MS); 








然后 在 刚刚 的 loadDfsUsed 方 法 中 替换 硬 编 码 值 600000L， 并 更 新 方法 的 注释 : 





long loadDfsUsed() { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 


// 将 600000 值 替换 为 变量 cachedDfsUsedCheckTime 













































































if (mtime > 0 && (Time.now() - mtime < cachedDfsUsedCheckTime)) { 
FsDatasetImpl .LOG.info ("Cached dfsUsed found for " + currentDir + ": "+ 
cachedDfsUsed); 
return cachedDfsUsed; 
} 
return -1; 
} finally { 
sc.close(); 
人 
} 
最 后 在 Hadoop 项 目 中 的 hdfs-default.xml 文 件 里 加 上 新 的 配置 项 以 及 描述 信息 
<property> 
<name>dfs.datanode.cached-dfsused.check.interval .ms</name> 
<value>600000</value> 
<description>DfsUsed 缓 存 文件 的 间隔 检查 时 间 ， 默 认 10 分 钟 
</description> 
</property> 
下 面 编 写 相应 单元 测试 实例 进行 测试 ， 单 元 测试 在 后 面 的 patch 链 接 中 会 给 出 。 在 DataNode 节 点 上 重新 部 署 新 的 jar 包 。 重 启 DataNode， 重 新 进行 慢 启动 场景 测试 ， 出 现下 面 这 个 记录 ， 说 明 是 使 用 了 
DfsUsed 缓 存 值 ， 启 动 过 程 非常 快 。 
2016-01-13 09:13:20,639 INFO [Thread-68] (FsVolumeList.java:402) - Scanning block pool BP-1543590671-xx.xx.xx.xx-1449897014835 on volume /home/data/data/hadoop/dfs/data/data9/ 
2016-01-13 09:13:20,639 INFO [Thread-69] (FsVolumeList.java:402) - Scanning block Pool BP-1543590671-xx.xx.xx.xx-1449897014835 on volume /home/data/data/hadoop/dfs/data/datalC 
2016-01-13 09:13:20,639 INFO [Thread-71] (FsVolumeList.java:402) - Scanning block pool BP-1543590671-xx.xx.xx.xx-1449897014835 on volume /home/data/data/hadoop/dfs/data/datal2 
2016-01-13 09:13:20,639 INFO [Thread-70] (FsVolumeList.java:402) - Scanning block pool BP-1543590671-xx.xx.xx.xx-1449897014835 on volume /home/data/data/hadoop/dfs/data/datall 
2016-01-13 09:13:20,822 INFO [Thread-62] (BlockPoolSlice.java:221) -~ Cached dfsUsed found for /home/data/data/hadoop/dfs/data/data3/current/BP-1543590671-xx.xx.xx.xx-144989701 
2016-01-13 09:13:20,825 INFO [Thread-63] (BlockPoolSlice.java:221) - Cached dfsUsed found for /home/data/data/hadoop/dfs/data/data4/current/BP-1543590671-xx.xx.xx.xx-144989701 
2016-01-13 09:13:20,825 INFO [Thread-62] (FsVolumeList.java:407) - Time taken to Scan block pool BP-1543590671-xx.xx.xx.xx-1449897014835 on /home/data/data/hadoop/dfs/data/dat 
2016-01-13 09:13:20,826 INFO [Thread-63] (FsVolumeList.java:407) - Time taken to scan block pool BP-1543590671-xx.xx.xx.xx-1449897014835 on /home/data/data/hadoop/dfs/data/dat 


此 新 配置 功能 笔者 已 提交 开源 社 





内 


9.2 ”Hadoop 中 止 下 线 操作 后 大 量 剩余 复制 块 问题 











Hadoop 集 群 在 使 





的 过 程 中 ， 经 常会 伴随 着 节 








节点 的 更 新 替换 : 老 的 、 





理 过 程 ， 随 后 给 出 针对 此 现象 的 解决 方案 。 为 了 进行 


9.2.1 ”节点 下 线 操作 的 含义 及 问题 


这 里 要 解释 一 个 略 显 专业 的 名 词 : 
点 资源 的 计算 能 力 。 在 Hadoop 中 下 线 操 作 最 重要 的 还 是 两 个 字 
的 重新 复制 ， 来 达到 HDFS 默 认 的 三 副本 数据 备份 的 策略 。 当 这 些 数据 都 拷贝 





岂 


旧 的 节点 下 线 ， 新 的 节 
我 们 会 看 到 大 量 的 副本 块 准备 复制 。 但 是 此 时 如 果 我 们 对 下 线 节 点 进行 停止 下 线 的 操作 ， 


， 编 号 为 HDFS-9624， 些 JIRA 中 的 patch 链 接 如 下 : https://issues.apache.org/jira/secure/attachment/12782424/HDFS-9624.007.patch 


点 上 线 。 在 节点 下 线 的 过 程 中 ，HDFS 为 了 保持 副本 数 的 统一 ， 
本 块 是 否 就 不 用 进行 复制 了 呢 ? 本 节 所 要 讲述 的 内 容 就 是 基于 这 


会 对 下 线 节点 中 的 副本 做 统一 的 复制 ， 随 后 
个 场景 。 在 下 文中 ， 将 详细 讲述 节点 下 线 的 














这 些 副 











一 定 的 比较 ， 本 节 还 将 举 出 Dead Node 重 启 的 例子 。 


节点 下 线 。 对 应 的 单词 是 Decommision， 大 意 就 是 说 将 一 个 节点 从 集群 中 移 除 ， 不 会 对 集群 造成 影响 。 但 是 有 一 点 很 明确 ， 下 线 操作 必然 会 导致 集群 失去 大 约 一 个 节 
: 数据 。 如 何 保证 下 线 节点 中 的 数据 能 够 完全 转移 到 其 他 机 器 中 ， 这 才 是 最 关键 的 。 所 以 在 DataNode 的 下 线 过 程 中 ， 做 的 主要 操作 还 是 块 


完毕 后 ，DataNode 的 节点 状态 会 变 为 Decommissioned 状 态 。 


这 个 时 候 就 可 以 停止 DataNode， 彻 底 将 机 器 关机 并 从 集群 中 移 


本 节 不 是 主要 介绍 DataNode 下 线 操 作 ， 下 线 操作 中 出 现 的 问题 才 是 本 节 所 重点 关注 的 内 容 。 当 你 对 普通 机 器 进行 下 线 操作 时 ， 如 果 没 有 什么 意外 情况 ， 过 程 会 比较 顺利 。 但 是 当 你 执行 完 节点 下 线 操 








作 后 ， 有 的 时 候 会 出 现下 面 两 种 情形 : 
“ 你 发 现 这 其 实 是 一 个 误 操作 ， 误 将 nodeA 节 点 加 入 到 dfs.exclude 文 件 中 了 。 


“ 你 受到 上 级 指示 ， 这 个 节点 暂时 不 进行 下 线 ， 重 新 调 回 正常 服务 状态 。 





上 述 两 种 情况 发 生 后 ， 你 的 第 一 反应 就 是 将 节点 从 exclude 文 件 中 移 掉 ， 并 重新 执行 dfsadmin-refreshNodes 命 令 。 当 然 你 会 很 高 兴 地 看 到 ， 节 点 的 状态 确实 重新 变 为 了 In Service 的 状态 了 。 但 是 如 果 
再 仔细 一 点 的 话 ， 你 会 发 现 NameNode 页 面 上 的 UnderReplicatedBlocks 块 的 个 数 并 没有 减少 ， 依 然 是 中 止 下 线 操作 前 的 数值 。 这 些 待 复制 的 块 基 本 就 是 原 下 线 节 点 上 存储 的 那些 块 ， 见 图 9-2。 








Security is off, 
Safemode is off. 
) 
Heap Memory used 312.15 MB of 953.5 MB Heap Memory Max Heap Memory is 953.5 MB. 
Non Heap Memory used 39.66 MB of 40.31 MB Commited Non Heap Memory Max Non Heap Memory is 130 MB 


Configured Capacity: 294.92 GB 


DFS Used: 1.03 GB (0.35%) 


Non DFS Used: 43.02 Gi 


B 


DFS Remaining: 250.87 GB (85.07%) 


Block Pool Used: 1.03 GB (0.35%) 














DataNodes usages (Min/Median/Max/stdDev): 0.32% /0.32% /0.41% /0.04% 


Live Nodes 3 (Decommissioned: 0) 


Dead Nodes 0 (Decommissioned: 0) 


Decommissioning Nodes 
Total Datanode Volume Fallures 
Number of Under-Replicated Blocks 


Number of Blocks Pending Deletion 


Block Deletion Start Time 2016/1/21 下 午 3:10:58 





9-2 NameNode 的 UnderReplicatedBlocks 计 数值 





























显然 当下 线 节 点 恢复 后 ， 这 些 大 量 的 复制 块 是 不 需要 的 ， 因 为 这 会 持续 占用 NameNode 的 时 间 去 处 理 这 些 待 复制 的 块 。 而 且 在 最 后 NameNode 会 频繁 地 发 现 ， 集 群 中 已 经 存在 足够 的 块 副本 了 。 当 有 
大 量 的 待 复制 块 时 ， 那 对 NameNode 来 说 简直 就 是 灾难 ， 甚 至 会 直接 影响 到 NameNode 正 常 的 请 求 处 理 。 从 这 里 可 以 看 出 ， 这 不 会 是 一 个 小 问题 。 在 后 面 的 内 容 中 笔者 将 会 介绍 一 套 完整 的 解决 方案 。 在 
























































这 之 前 ， 为 了 进行 对 比 ， 下 面 再 介绍 一 种 类 似 大 量 残 余 复 制 块 的 场景 。 





9.2.2” 死 节点 “复活 ” 


出 现 大 量 复制 块 的 另外 一 个 场景 是 出 现 死 节点 (Dead Node) 。 当 一 个 DataNode 长 时 间 不 汇报 心跳 ， 超 过 心跳 检测 超时 时 间 后 ， 此 DataNode 就 会 被 认为 是 Dead Node。 出 现 了 Dead Node 后 , 为 
了 达到 副本 块 的 平衡 ， 同 样 会 进行 大 量 块 的 拷贝 ， 与 下 线 操作 极为 类 似 。 但 是 这 里 有 一 个 主要 的 不 同 点 ， 当 Dead Node 重 启 之 后 ， 这 些 残 余 复 制 块 过 一 会 就 会 减少 到 Dead Node 之 前 的 正常 值 (大 家 可 以 











自行 执行 这 个 操作 进行 验证 ) 。 两 种 场景 ， 相 似 的 现象 ， 完 全 不 同 的 结果 。Dead Node 恢 复 的 情况 才 是 我 们 想 看 到 的 结果 。 那 么 为 什么 Dead Node 的 恢复 会 使 得 复制 块 减少 ， 而 下 线 恢复 操作 则 不 会 呢 ? 
解决 这 个 问题 的 唯一 办 法 还 是 得 从 源码 中 寻找 ， 光 猜 是 永远 解决 不 了 问题 的 。 一 旦 发 现 这 个 答案 ， 一 定 有 助 于 我 们 用 相同 的 办 法 解决 下 线 操 作 时 大 量 复制 块 残留 的 问题 。 























本 节 内 容 的 焦点 始终 围绕 着 “复制 块 ”， 那 么 在 HDFS 的 代码 中 ， 这 个 变量 到 底 是 被 哪个 对 象 类 所 控制 呢 ， 找 到 这 个 变量 、 方 法 很 关键 。 答 案 在 FSNamesystem 类 中 ， 代 码 如 下 : 








Override // FSNamesystemMBean 
Q@Metric 
public long getUnderReplicatedBlocks() { 
return blockManager .getUnderReplicatedBlocksCount (); 
} 





进一步 往 里 走 ， 进 入 BlockManager 中 : 





public long getUnderReplicatedBlocksCount () { 
return underReplicatedBlocksCount; 
} 





这 个 变量 被 谁 所 赋值 的 呢 ， 继 续 往 下 看 : 





void updateState () { 

pendingReplicationBlocksCount = pendingReplications.size(); 
// 赋值 还 需要 复制 的 副本 数 
underReplicatedBlocksCount = neededReplications.size(); 
corruptReplicaBlocksCount = corruptReplicas.size(); 

















就 是 中 间 这 行 代码 ， 变 量 名 称 表 明了 它 的 意思 : neededReplications， 需 要 被 复制 的 副本 。 我 们 基本 可 以 推断 出 ，DataNode 在 寻 


重启 之 后 ,会 调 














neededReplication 的 移 除 块 类 似 的 操作 ， 从 而 使 得 


该 变量 的 大 小 减少 。 然 后 我 们 再 次 进行 联想 ， 当 DataNode 进 行 重启 之 后 ， 会 首先 进行 节点 的 注册 动作 ， 之 后 会 进行 心跳 的 发 送 ， 在 发 送 心跳 的 时 候 会 进行 块 的 上 报 ， 在 块 上 报 的 时 候 显然 是 一 个 绝 佳 的 机 
会 。 当 然 这 只 属于 目前 的 猜想 ， 我 们 通过 分 析 代 码 来 验证 这 个 初始 猜想 。 我 们 进入 处 理 心跳 相关 的 循环 方法 ，BpServiceActor 的 offerService 方 法 : 











private void offerService () throws Exception { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


while (shouldRun()) { 
try { 
final long startTime = scheduler.monotonicNow(); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


Pad 建生 天 的 下 报 
List<DatanodeCommand> cmds = blockReport (); 
processCommand (cmds == null ? null : cmds.toArray (new DatanodeCommand[cmds.size()])); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 操作 中 ， 可 以 看 到 会 有 blockReport 的 操作 ， 并 得 到 了 NameNode 返 回 给 DataNode 的 回复 命令 ， 进 入 blockReport 方 法 : 








List<DatanodeCommand> blockReport () throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 接 下 来 准备 发 送 块 报告 到 NameNode 
int numReportsSent = 0; 
int numRPCs = 07 
boolean success = false; 
long brSendStartTime = monotonicNow(); 
long reportId = generateUniqueBlockReportId(); 
try { 
if (totalBlockCount < dnConf.blockReportSplitThreshold) { 
// 发 送 块 报告 到 NameNode 
DatanodeCommand cmd = bpNamenode.blockReport ( 
bpRegistration, bpos.getBlockPoolId(), reports, 
new BlockReportContext (1, 0, TeportId) ) 7 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 这 里 ， 就 可 以 看 到 DataNode 将 块 真正 汇报 给 了 NameNode， 对 应 到 NameNode 的 RpcServer 端 





QOverride // DatanodeProtocol 
public DatanodeCommand blockReport (DatanodeRegistration nodeReg, 
String poolId, StorageBlockReport[] reports, 
BlockReportContext context) throws IOException { 
checkNNSstartup(); 
verifyRequest (nodeReg); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/.. 
// BlockManager 进 行 上 报 块 的 处 理 
noStaleStorages = bm.processReport (nodeReg, reports[r] .getStorage(), 
blocks, context, (r 一 reports.length - 1)); 
metrics.incrStorageBlockReportOps (); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 




















在 BlockManager 的 processBlock 方 法 内 还 有 几 层 方法 ， 这 里 给 出 最 后 会 调用 移 除 复制 块 动作 的 方法 ， 如 下 所 示 : 











private Block addstoredBlock (final BlockIinfoContiguous block, 
DatanodeStorageInfo storageInfo, 
DatanodeDescriptor delNodeHint, 
boolean logEveryBlock) 
throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/. 
21 款 所 此 抉 期望 达 到 的 副本 数 
Short fileReplication = bc.getBlockReplication(); 
// 判断 是 否 还 需要 再 复制 副本 
if (1isNeededqReplication (storedBlock，fileReplication，numCurrentReplica)) { 
// 不 需要 了 则 进行 移 除 
neededReplications.remove (storedBlock, numCurrentReplica, 
num.decommissionedReplicas(), fileReplication); 
} else { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 











在 这 里 会 重新 进行 副本 块 的 判断 ， 如 果 不 需 要 副本 了 ， 则 会 从 neededReplications 对 象 中 进行 删除 ， 因 此 才 会 出 现 待 复制 块 减少 的 现象 。 其 实 还 
上 报 给 了 NameNode。 而 下 线 节 点 从 下 线 状 态 变 为 正常 服务 状态 ， 节 点 不 会 进行 重新 注册 的 动作 ， 原 始 的 块 没有 被 修改 过 也 是 不 会 上 报 的 ， 才 会 有 了 以 上 两 种 截然 不 | 











9.2.3 ”Decommission 下 线 操作 如 何 运 作 











是 多 亏 了 DataNode 奸 


新 注册 的 动作 ， 把 自身 的 所 有 块 





同 的 结果 


这 里 是 本 节 的 一 个 分 界线 ， 上 半 部 分 通过 现象 找 出 问题 的 根源 ， 而 下 半 部 分 则 是 学 习 原 理解 决 问题 。 要 解决 Decommision 下 线 操 作 中 大 量 复制 块 残留 的 问题 ， 要 首先 明白 它 的 运行 逻辑 。 我 们 都 知道 ， 


下 线 相关 动作 是 通过 -refreshNodes 命 令 触发 的 ， 对 应 会 执行 到 DatanodeManager 的 refreshDatanodes 方 法 : 








// 刷新 节点 方法 
Private void refreshDatanodes() { 
for (DatanodeDescriptor node : datanodeMap.values()) { 
// 判断 是 否 包 含 在 indude 文 件 中 
if (!hostFileManager.isIncluded(node)) { 
node . ee 
} else 
// 各 未 it 点 在 exclude 文 件 中 ， 则 表明 需要 下 线 ， 进 行 下 线 操 作 
if (hostFileManager.isExcluded (node)) { 
startDecommission (node); 





} else 
// 震中 对 此 节 点 进行 中 止 下 线 操作 
decomManager .stopDecommission (node); 





} 
} 
} 
} 





在 这 里 我 们 关注 的 方面 有 2 个 : 一 个 是 开始 下 线 操作 ， 另 外 一 个 则 是 中 止 下 线 操作 。 
1. 开 始 下 线 


在 开始 下 线 操作 后 ， 待 复制 块 是 如 何 被 加 入 到 needReplications 这 个 对 象 里 去 的 呢 ? 如 下 代码 所 示 : 





Public void startDecommission (DatanodeDescriptor node) { 


if (!node.isDecommissionInProgress()) { 
if (!Inode.isAlive) { 
LOG.info("Dead node {} is decommissioned immediately.", node); 


node.setDecommissioned (); 
else if (!Inode.isDecommissioned()) { 
for (DatanodeStorageInfo storage : node.getStorageInfos()) { 
LOG.info("Starting decommission of {} {} with {} blocks", 
node, storage, storage.numBlocks()); 


} 
// 在 HeartbeatManager 中 更 新 此 节点 的 状态 信息 ， 将 会 被 标记 为 下 线 中 的 状态 
hbManager .startDecommission (node); 


node .decommissioningStatus .setStartTime (monotonicNow()); 
// 将 目标 下 线 节点 加 入 pendingNodes 列 表 中 
pendingNodes .add (node); 





http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















在 代码 的 最 后 一 行 ， 这 个 节点 被 加 入 到 了 pendingNodes 列 表 中 。 如 果 各 位 同学 之 前 研究 过 DecommisionManager 这 个 类 ， 应 该 知道 里 面 会 有 一 个 专门 的 线程 


此 监控 类 代码 定义 如 下 : 

















以 监视 下 线 中 的 节点 是 否 已 经 结束 。 





private class Monitor implements Runnable { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


QOverride 
public void run() { 
if (!Inamesystem.isRunning()) { 


LOG.info ("Namesystem is not running, skipping decommissioning checks" 


+ 
return; 


} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





在 run 方 法 中 ， 会 进行 2 个 操作 : 





QOverride 
public void run() { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


try 4 
processPendingNodes (); 
check (); 
} finally { 
namesystem.writeUnlock (); 
- 
if (numBlocksChecked + numNodesChecked > 0) { 


LOG.info("Checked {} blocks and {} nodes this tick", numBlocksChecked, 


numNodesChecked); 














processPendingNodes 的 作用 是 将 之 前 加 入 到 pendingNodes 对 象 中 的 节点 逐步 移出 到 下 线 节点 中 : 














Private void ProcessPendingNodes () { 
while (!PendingNodes .isEmpty() && 
(maxConcurrentTrackedNodes == 11 
decomNodeBlocks.size() < maxConcurrentTrackedNodes)) { 
// 将 之 前 加 入 到 pendingNodes 列 表 中 的 待 下 线 节点 加 入 到 decomNodeBlocks 中 
decomNodeBlocks .put (pendingNodes .poll1 (), null); 
} 
} 





check 方 法 才 是 真正 的 块 扫描 操作 ， 判 断 是 否 还 有 副本 数 不 足 的 块 : 





private void check() { 


final Iterator<Map.Entry<DatanodeDescriptor, AbstractList<BlockInfoContiguous>>> 


it = new CyclicIteration<>(decomNodeBlocks, iterkey) .iterator () 7 
final LinkedList<DatanodeDescriptor> toRemove = new LinkedList<>(); 


while (it.hasNext () 
&& lexceededNumBlocksPerCheck () 
&& !exceededNumNodesPerCheck()) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


if (blocks == null) { 
// 这 是 一 个 新 添加 的 下 线 节 点 ， 需 要 进行 全 盘 的 扫描 来 确定 哪些 块 
// 还 需要 进行 复制 
LOG.debug ("Newly-added node {}, doing full scan to find "+ 
"insufficiently-replicated blocks.", dn); 
blocks = handleInsufficientlyReplicated (dn); 
decomNodeBlocks.put (dn, blocks); 
fullSscan = true; 
} else { 








// 继续 检测 此 节点 上 是 否 还 有 需要 再 复制 的 块 ， 直 到 上 面 的 块 已 全 部 复制 完毕 ， 以 此 达到 副本 数 的 要 求 


LOG.debug ("Processing decommission-in-progress node {}", dn); 
pruneSufficientlyReplicated (dn, blocks); 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





check 方 法 内 的 判断 逻辑 比较 多 ， 归 纳 地 来 说 是 持续 判断 是 否 还 存在 副本 数量 不 足 的 块 ， 不 够 则 继续 监控 ， 直 到 这 个 数值 为 0， 然 后 从 下 线 节点 中 移 除 
handlelnsufficientlyReplicated 内 部 函数 的 操作 中 ， 会 将 副本 数量 不 足 的 块 加 入 到 neededReplication 中 。 


趣 的 同学 ， 可 以 自行 研究 。 在 





private void processBlocksForDecomInternal ( 
final DatanodeDescriptor datanode, 
final Iterator<BlockInfoContiguous> it, 
final List<BlockInfoContiguous> insufficientlyReplicated, 
boolean pruneSufficientlyReplicated) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 利用 DataNode 上 的 友 代 器 对 象 ， 进 行 块 的 遍历 
while (it.hasNext()) { 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 获取 块 当前 的 副本 数 

final NumberReplicas num = blockManager .countNodes (block); 
final int liveReplicas = num.liveReplicas(); 

final int curReplicas = liveReplicas; 


// 判断 此 块 是 否 还 需要 进行 副本 的 复制 
if (blockManager.isNeededReplication (block, bc.getBlockReplication(), 


liveReplicas)) { 
if (!blockManager.neededReplications.contains (block) && 
blockManager .pendingReplications.getNumReplicas (block) == 0 && 


namesystem.isPopulatingReplQueues()) { 
// 如 果 还 需要 ， 则 会 加 入 到 BlockManager 的 neededReplication 列 表 中 ， 
// 等 待 进行 此 副本 的 复制 
blockManager .neededReplications.add (block, 
curReplicas, 
num.decommissionedReplicas(), 
bc.getBlockReplication()); 
} 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 





这 也 就 是 为 什么 待 复制 块 骤然 增加 的 原因 。 





2. 中 止 下 线 


那 中 止 下 线 的 过 程 中 又 做 了 什么 操作 呢 ? 至 少 有 一 点 我 们 可 以 确定 ， 它 没有 将 原本 存在 于 下 线 节 点 中 的 块 从 neededReplications 对 象 中 移 除 掉 。 





void stopDecommission (DatanodeDescriptor node) { 


if (node.isDecommissionInProgress() || node.isDecommissioned()) { 
LOG.info("Stopping decommissioning of node {}", node); 
// HeartbeatManager 更 新 此 节点 的 人 
hbManager stopDecommission( (node); 
// 清除 之 前 下 线 过 程 让 各 复 出 光 人 必 和 本 块 
if (node.isAlive) { 
blockManager .processOverReplicatedBlocksOnReCommission (node); 











. 
// 在 DecommissionManager 对 象 中 移 除 此 节点 
pendingNodes .remove (node); 
decomNodeBlocks .remove (node); 
} else { 
LOG.trace ("stopDecommission: Node {} is not decommission in progress " + 
"or decommissioned, nothing to do.", node); 





操作 并 不 多 ， 可 以 看 到 这 里 只 是 将 下 线 节 点 移 除 ， 还 做 了 多 余 副 本 块 的 清除 ， 这 些 副本 块 是 之 前 下 线 状态 中 复制 的 那些 副本 块 。 的 确 少 了 我 们 所 需要 的 那个 移 除 动作 ， 所 以 我 们 需 
processOverReplicatedBlocksOnReCommission 方 法 之 后 增加 这 样 的 处 理 方法 。 


9.24 ”中 止 下 线 操作 后 移 除 残余 副本 块 解决 方案 


我 们 首先 在 DecommissionManager 这 个 类 中 定义 一 个 新 的 方法 ， 如 下 : 





// 对 指定 节点 判断 其 上 的 块 是 否 还 需要 复制 副本 
Private void removeNeededReplicatedBlocksInDecomNodes ( 
final DatanodeDescriptor datanode) { 
// 获取 块 欠 代 器 
final Tiarator. oo itoLonti gu it = datanode.getBlockIterator(); 
// 遍历 此 节点 上 的 块 
while (it.hasNext()) { 
final BlockInfoContiguous block = it.next (); 
BlockCollection bc = blockManager .blocksMap.getBlockCollection (block); 
if (bc == null) { 
// Orphan block, will be invalidated eventually. Skip. 
continue; 


E 





final NumberReplicas num = blockManager.countNodes (block); 
final int liveReplicas = num.liveReplicas(); 
final int curReplicas = liveReplicas; 
// 判断 是 否 需要 复制 此 副本 
if (!blockManager. ep ca on (block, bc.getBlockReplication(), 
liveReplicas)) 
// 如 果 不 需 要 ， 莲 行 移 除 
blockManager .neededReplications.remove (block, curReplicas, 
num.decommissionedReplicas(), bc.getBlockReplication()); 








逻辑 很 简单 ， 判 断 是 否 还 需要 副本 ， 如 果 不 需 要 则 进行 移 除 。 而 传 入 的 节点 就 是 原 下 线 节 点 ， 有 点 重新 注册 的 意思 在 里 面 。 然 后 加 入 到 stopDecommission 操 作 中 ， 修 改 后 的 代码 如 下 : 











void stopDecommission (DatanodeDescriptor node) { 
if (node.isDecommissionInProgress() || node.isDecommissioned()) { 

LOG.info("Stopping decommissioning of node {}", node); 

// 获取 节点 之 前 的 下 线 状 态 

Adminstates adminState = node.getAdminstate () 7 

// HeartbeatManager 更 新 此 才 节点 的 信息 

hbManager. stopDecommission ( (noge); 

// 之 前 下 线 过 程 下 生发 生前 区 实 册 采 诡 村 人 被 清除 

if (node.isAlive) { 
blockManager. processOverReplicatedBlocksOnReCommi ssion (nogde); 
// 在 此 新 增 移 除 块 方法 ， 只 有 当 节点 之 前 的 状态 为 下 线 中 时 才 有 必要 执行 
if (adminState == AdminStates.DECOMMISSION INPROGRESS) { 

removeNeededReplicatedBlocksInDecomNodes (node); 











} 


} 
// 在 DecommissionManager 中 移 除 当前 传 入 的 节点 
pendingNodes .remove (node); 
decomNodeBlocks .remove (node); 
} else { 
LOG.trace ("stopDecommission: Node {} is not decommission in progress " + 
"or decommissioned, nothing to do.", node); 














这 里 需要 判断 一 下 节点 状态 ， 因 为 如 果 节 点 已 经 是 Decommissioned 状 态 ， 那 么 表明 待 复制 块 基本 已 经 被 复制 完了 ， 这 个 操作 意义 不 大 。 下 面 附 上 单元 测试 代码 ， 测 试 已 通过 。 








QTest 
public void testDecommissionRemovingNeededReplicatedBlocks () 
throws IOException, InterruptedException { 

int underReplicatedBlocksNum; 
int neededReplicatedBlocksNum; 
int sleepIntervalTime = 5000; 
int numNamenodes = 1; 
int numDatanodes = 2; 
// 设置 块 副本 数 为 集群 中 的 DataNode 数 量 ， 借 此 让 每 个 节点 恰好 包含 一 个 
// 文件 所 包含 的 所 有 块 
int replicas = numDatanodes; 
conf.setInt (DFSConfigKeys.DFS REPLICATION KEY, replicas); 
startCluster (numNamenodes, numDatanodes, conf); 


ArrayList<ArrayList<DatanodeInfo>> namenodeDecomList = 
new ArrayList<ArrayList<DatanodeInfo>> (numNamenodes); 
for (int i = 0; i < numNamenodes; i++) { 
namenodeDecomList.add (i, new ArrayList<DatanodeInfo> (numDatanodes)); 
} 


// 计算 每 个 文件 需要 存储 的 块 总 数 
neededReplicatedBlocksNum = (int) Math.ceil(1.0 * fileSize / blockSize); 
Path file = new Path("testDecommission.dat"); 
for (int iteration = 0; iteration < numDatanodes - 1; :iteration++) { 
// 准备 开始 下 线 操作 
for (int i = 0; i < numNamenodes; i++) { 
FileSystem fileSys = cluster.getFileSystem(i); 
FSNamesystem ns = cluster.getNamesystem(i); 
BlockManager blcokManager = ns.getBlockManager (); 
/让 写 入 文件 到 集 说 


writerFile (fileSys, file, replicas); 


DFSClient client = getDfsClient (cluster.getNameNode (i), conf); 
DatanodeInfo[] info = client.datanodeReport (DatanodeReportType.LIVE); 


ArrayList<String> decommissionedNodes = new ArrayList<String>(); 
decommissionedNodes.add (info[0] .getXferAddr ()); 
// 写 入 待 下 线 节点 到 exclude 文 件 
writeConfigFile (excludeFile, decommissionedNodes); 

// 执行 刷新 节点 方法 ， 开 始 下 线 目标 节点 
refreshNodes (cluster. a 7 EGREJ 7 
// Return the datanode descriptor for the given datanode. 
NameNodeAdapter .getDatanode (cluster .getNamesystem(i), info[0]); 


// 睡眠 等 待 一 段 时 间 让 DecommissionManager 内 的 监控 线程 去 扫描 








// 下 线 中 的 块 

Thread.sleep (sleepIntervalTime); 
underReplicatedBlocksNum = 

_blcokManager. getUnderReplicatedNotMi ssingBlocks ( jx 
// 下 线 节点 中 待 复制 的 副本 数 应 该 等 于 一 个 文件 所 包含 的 总 块 数 





assertEquals (neededReplicatedBlocksNum, underReplicatedBlocksNum); 


// 清空 下 线 节 点 

decommissionedNodes.clear ( 

// 将 空 节 点 写 入 exclude 配 置 ， 导 胃 下 时 准备 中 目下 线 操作 
writeConfigFile (excludeFile, decommissionedNodes); 
// 重新 执行 刷新 节 点 操作 


refreshNodes (cluster.getNamesystem(i), conf); 


// 重新 获取 待 复制 节点 数 
underReplicatedBlocksNum = 

blcokManager. ee oo 过 
// 中 止 下 线 操作 后 ， 待 复制 副本 数理 应 被 清空 ， 数 值 应 为 0 
assertEquals (0, underReplicatedBlocksNum); 


cleanupFile (fileSys, file); 
} 
} 


// 测试 结束 ， 关 闭 集群 
cluster.shutdown (); 
startCluster (numNamenodes, numDatanodes, conf); 
cluster.shutdown (); 








解决 方案 就 是 以 上 的 几 十 行 代码 ， 但 是 要 写 出 上 述 的 几 十 行 代码 ， 需 要 我 们 对 HDFS 下 线 机 制 以 及 周边 原理 的 了 解 ， 其 实 并 没有 想象 得 那么 简单 。 希 望 大 家 有 所 收获 ， 针 对 这 个 问题 ， 同 样 地 笔者 已 提交 


开源 社区 





， 编 号 为 HDFS-9685。 


9.3 ”DFSOutputStream 的 DataStreamer 线 程 泄漏 问题 





DFSOutputStream 类 是 HDFS 中 的 数据 写 出 类 ， 此 类 控制 着 HDFS 数 据 块 的 写 出 操作 。 在 DFSOutputStream 类 内 部 ， 通 过 DataStreamer、ResponseProcessor 对 象 之 间 的 合作 ， 最 终 完 成 了 数据 包 的 
传输 与 写 出 。 但 是 在 程序 运行 的 过 程 中 ，DataStreamer 存 在 部 分 线程 泄漏 的 问题 。 本 节 将 首先 为 大 家 介绍 DFSOutputStream 内 部 的 数据 处 理 过 程 ， 然 后 在 本 节 末 尾 对 DataStreamer 的 线程 泄漏 问题 进行 
一 定 地 分 析 并 给 出 解决 方案 。 


93.1 Bb 


本 节 了 

















FSOutputStream 写 数据 过 程 及 周边 相关 类 、 变 量 


EF 要 讲述 的 是 DataNode 写 数据 的 过 程 ， 在 写 数据 的 过 程 中 ， 第 一 个 联想 到 的 就 是 DFSOutputStream 对 象 类 。 但 其 实 这 只 是 其 中 的 一 个 大 类 ， 它 的 内 部 还 包括 了 数据 写 出 的 许多 类 对 象 。 下 面 主 


介绍 这 几 个 类 。 


1.DataStreamer 


数据 






























































充 类 ， 这 是 数据 写 操作 时 调用 的 主要 类 。DFSOutputStream 的 start 方 法 调用 的 就 是 DataStreamer 线 程 run 方 法 。DFSOutputStream 的 主要 操作 都 是 依靠 内 部 对 象 类 DataStreamer 来 实现 的 ， 可 











以 说 二 者 的 联系 最 为 紧密 。 


2.ResponseProcessor 


ResponseProcessor 类 是 DataStreamer 中 的 内 部 类 ， 主 要 作 





























是 接收 Pipeline 中 DataNode 的 ACK 回 复 。 它 是 一 个 线程 类 ， 以 下 为 源码 中 的 注释 : 











处 理 下 游 DataNode 返 回 的 回复 信息 。 当 有 新 的 回复 抵达 的 时 候 ， 数 据 包 将 会 从 ACK 队 列 中 移 除 。 


3.DFSPacket 














数据 包 类 ， 在 DataStreamer 和 DFSOutputStream 中 都 是 用 这 个 类 进行 数据 的 传输 ， 以 下 为 源码 中 的 注释 : 











DFSPacket 对 象 被 DataStreamer 和 DFSOutputStream 所 共同 使 用 。DFSOutputStream 产 生 这 些 数 据 包 对 象 ， 然 后 让 DataStreamer 对 象 发 送 这 些 数据 包 到 DataNode 上 。 





除了 以 上 3 个 大 类 需要 了 解 之 外 ， 还 有 几 个 变量 同样 需要 重视 ， 因 为 这 些 变量 会 在 后 面 的 分 析 中 经 常 出 现 : 
































:dataQueue (List<DFSPacket>) : 待 发 送 数 据 包 列表 。 





ackQueue (List<DFSPacket>) : 数据 包 回 复 列表 。 数 据 包 发 送 成 功 后 ，DFSPacket 将 会 从 dataQueue 移 到 ackQueue 中 。 


“ Pipeline: Pipeline 是 一 个 常见 的 名 词 ， 中 文 翻译 的 意思 是 “管道 ”， 但 是 笔者 认为 对 此 更 好 的 理解 方式 是 “流水 线 模型 ”。Pipeline 中 的 DataNode 拥 有 它 上 游 的 节点 以 及 下 游 的 节点 。 


9.3.2 ”DataStreamer 数 据 流 对 象 














要 了 解 写 数 据 的 细节 ， 需 要 先 了 解 DataStreamer 的 实现 机 理 ， 因 为 DFSOutputStream 的 主 操作 无 非 是 调用 了 DataStreamer 的 内 部 方法 。DataStreamer 源 码 中 的 注释 很 好 地 解释 了 DataStreamer 所 














要 做 的 事 ， 





下 面 是 对 其 简要 的 概述 。 























DataStreamer 对 象 类 主要 负责 发 送 数 据 包 到 Pipeline 的 各 个 DataNode 中 。 它 会 从 NameNode 中 寻求 一 个 新 的 块 1d 和 块 的 位 置信 息 ， 然 后 开始 以 流 式 的 方式 对 Pipeline 中 的 DataNode 进 行 数据 包 的 传 
输 。 每 个 包 有 属于 它 自己 的 一 个 数字 序列 号 。 当 属于 一 个 块 的 所 有 的 数据 包 发 送 完 毕 并 且 对 应 的 ACK 回 复 都 被 接收 到 了 ， 则 表明 此 次 的 块 写 入 完成 ，DataStreamer 将 会 关闭 当前 块 。DataStreamer 线 程 从 
dataQueue 中 选取 数据 包 ， 发 送 此 数据 包 给 Pipeline 中 的 首 个 DataNode。 然 后 移动 此 数据 从 dataQueue 列 表 到 ackQueue。ResponseProcessor 会 从 各 个 DataNode 中 接收 ACK 回 复 。 


对 于 每 一 个 发 送 的 数据 包 而 言 ， 只 有 当 Pipeline 中 的 DataNode 都 发 送 了 成 功 的 ACK 回 
现 错 误 的 时 候 ， 所 有 未 完成 的 数据 包 将 会 从 ackQueue 中 移 除 掉 。 会 重新 建立 


















































复 ， 才 表明 此 数据 包 已 成 功 写 入 节点 。 然 后 ResponseProcessor 将 会 从 ackQueue 列 表 中 移 除 相应 的 数据 包 。 当 出 





一 个 新 的 Pipeline， 移 除 掉 坏 的 DataNode， 然 后 DataStreamer 会 从 dataQueue 中 重新 发 送 此 数据 包 。 





总 体 过 程 大 致 如 此 ， 想 必 大 家 或 多 或 少 已 经 对 其 中 的 过 程 有 所 了 解 。 图 9-3 为 Datastreamer 数 据 流 的 相关 结构 。 




















司 9-3 对 应 的 程序 逻辑 在 run 方 法 中 。 首 先 在 while 循 环 中 会 获取 一 个 数据 包 : 





one = 


dataQueue .getFirst (); 





DataStreamer 









initDataStreaming 





ResponsePro 








movePacket 
getPacket 








DfsOutputStream 


dataQueue(List<DfsPacket>) ackQueuelList<DfsPacket>) 





图 9-3 ”DataStreamer 数 据 流 相关 结构 图 


在 接 下 来 的 操作 中 会 出 现 数据 包 的 转移 : 





// 下 面 开始 发 送 数 据 包 
SpanId spanId = SpanId.INVALID; 
synchronized (dataQueue) { 
// 移动 数据 包 从 dataQueue 队 列 到 ackQueue 队 列 
if (!one.isHeartbeatPacket ()) { 
if (scope != null) { 
spanId = scope.getSpanId(); 
scope.detach () 
one.setTraceScope (scope); 
} 
scope = null; 
dataQueue. removeFirst (); 
ackQueue .addLast (one); 
dataQueue.notifyAll (); 








然后 发 送 数 据 到 远程 DataNode 节 点 : 





// 写 出 数据 到 远程 DataNode 节 点 
try (TraceScope ignored = dfsClient.getTracer () . 
newScope ("DataStreamer#writeTo", spanId)) { 
one.writeTo (blockStream); 
blockStream.flush () 7 
} catch (IOException e) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


























居 包 之 后 ，responseProcessor 进 程 会 收 到 来 自 DataNode 的 ACK 回 复 。 如 果 对 于 一 个 块 ， 收 到 了 Pipeline 中 DataNode 所 有 的 ACK 回 复 信息 ， 则 代表 这 个 块 发 送 完成 了 。 





dataStreamer 发 送 完 数 
Pipeline 的 DataNode 构 建 分 为 两 种 情况 ， 代 表 着 两 种 情形 的 数据 传输 : 


* BlockConstructionStage.PIPELINE_SETUP_CREATE 


* BlockConstructionStage.PIPELINE_SETUP_APPEND 


第 一 种 情况 ， 在 新 分 配 块 的 时 候 进 行 的 。 从 NameNode 上 获取 新 的 块 ld 和 位 置 ， 然 后 连接 上 第 一 个 DataNode。 





if (stage 一 BlockConstructionStage.PIPELINE SETUP CREATE) { 


if (LOG.isDebugEnabled()) { 
LOG.debug ("Allocating new block: " + this); 


a 
setPipeline (nextBlockOutputStream()); 


initDataStreaming () 7 
} 





nextBlockOutputStream 方 法 执行 如 下 ， 在 此 方法 中 将 会 连接 上 第 一 个 DataNode 节 点 : 





protected LocatedBlock nextBlockOutputStream() throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 连接 第 一 个 DataNode 
Success = CreateBlockOutputStream (nodes， storageTypes, 0L, false); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















Pipeline 的 第 一 阶段 如 图 9-4 所 示 。 








transfer data 


DataNode1i | DataNode2 一 -= 一 DataNode3 


ack 





网 


9-4 ”Pipeline 构 建 第 一 阶段 














另外 一 个 阶段 是 第 一 个 DataNode 节 点 向 其 他 剩余 节点 建立 连接 : 





} else if (stage == BlockConstructionStage.PIPELINE SETUP APPEND) { 
if (LOG.isDebugEnabled()) { 
LOG.debug ("Append to block {}", block); 
} 


setupPipelineForAppendOrRecovery (); 
if (streamerClosed) { 
continue; 


} 
initDataStreaming (); 





后 面 是 建立 连接 的 代码 : 





private void setupPipelineForAppendOrRecovery() throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


setupPipelineInternal (nodes, storageTypes); 


protected void setupPipelineInternal (DatanodeInfo[] datanodes, 


StorageType[] nodeStorageTypes) throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 建立 剩余 节点 的 连接 
success = createBlockOutputStream (nodes, storageTypes, newGS, isRecovery); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 

















第 二 阶段 过 程 如 图 9-5 所 示 。 









PIPELINE_SETUP_APPEND 


create and setup pipeline; 






transfer data transfer data 


DataNode1i | DataNode2 





[BEE 













9-5 Pipeline 构建 第 二 阶段 





网 








Pipeline 的 异常 重建 发 生 在 DataNode 10 的 异常 处 理 中 : 








public void run() { 
long lastPacket = Time.monotonicNow(); 
TraceScope scope = null; 
while (!streamerClosed && dfsClient.clientRunning) { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


DFSPacket one; 


try { 
// IO 错 误 处 理 
boolean doSleep = processDatanodeOrExternalError (); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 数据 流传 输出 错 处 理 


Private boolean processDatanodeOrExternalError() throws IOException { 

7/ 如果 没有 发 生出 鳃 情况 ， 则 下 加 

if (!errorState.hasDatanodeError() && !shouldHandleExternalError()) { 
return false; 


. 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


if (response != null) { 
LOG.info("Error Recovery for " + block + 
" waiting for responder to exit. "); 
return true; 
} 
// 关闭 当前 stream 对 象 


CloseStream() 7 


http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
// Pipeline 错 误 恢复 处 理 

setupPipelineForAppendOrRecovery (); 

http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 





9.3.3 ”ResponseProcessor 回 复 获取 类 


进入 ResponseProcessor 类 的 主 运行 方法 : 





public void run() { 


setName ("ResponseProcessor for block " + block); 
PipelineAck ack = new PipelineAck (); 


TraceScope scope = null; 
while (!responderClosed && dfsClient.clientRunning && !isLastPacketInBlock) { 


// 下 游 DataNode 回 复 信息 的 处 理 


try { 
// 从 Pipeline 中 读 取 一 条 ACK 返 回信 息 
long begin = Time.monotonicNow(); 
ack.readFields (blockReplyStream); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 














这 里 会 从 blockReplyStream 输 入 流 中 读 取 ACK 返 回信 息 ， 要 特别 注意 的 是 ， 这 里 读 到 的 ACK 与 之 前 ackQueue 中 的 ACK 并 不 是 同一 个 对 象 。 这 个 ACK 指 的 是 PipelineAck， 主 要 的 作用 是 获取 其 中 的 
seqno 序 列 号 。 

















long seqno = ack.getSeqno(); 





判断 是 否 是 有 效 的 块 回复 : 





assert seqno != PipelineAck.UNKOWN SEQNO : 
"Ack for unknown seqno should be a failed ack: " + ack; 
// 如 果 是 心跳 回复 信息 ， 则 跳 过 此 轮 处 理 
if (seqno 一 DFSPacket.HEART BEAT SEQNO) { 
continue; 


} 





然后 取出 ACK 的 DFSPacket 数 据 包 ， 比 较 序列 号 ,判断 是 否 一 致 : 





// 获取 一 个 数据 包 的 ACK 信 息 
DFSPacket one; 
synchronized (dataQueue) { 
one = ackQueue.getFirst (); 
} 
if (one.getSeqno() != seqno) { 
throw new IOException ("ResponseProcessor: Expecting seqno "+ 
™ for block " + block + 
one.getSeqno() + " but received " + seqno); 





此 ACK 回 复 包 判断 完毕 后 ， 会 进行 相应 数据 包 的 移 除 : 





synchronized (dataQueue) { 
scope = one.getTraceScope (); 
if (scope != null) { 
scope.reattach (); 
one.setTraceScope (nul1) 7 


} 

lastAckedSeqno = seqno; 
pipelineRecoveryCount = 0; 
ackQueue. removeFirst (); 
dataQueue.notifyAll (); 


one.releaseBuffer (byteArrayManager); 





至 此 ackQueue 中 的 数据 包 就 被 彻底 移 除 掉 了 ， 从 最 开始 加 入 到 dataQueue， 到 移动 到 ackQueue， 到 最 后 回复 的 确认 完毕 ， 进 行 最 终 的 移 除 。 





在 这 些 操作 执行 期 间 ， 还 会 进行 一 项 判断 : 





isLastPacketInBlock = one.isLastPacketInBlock(); 





如 果 此 数据 包 是 发 送 块 的 最 后 一 个 数据 包 ， 则 此 responseProcessor 线 程 将 会 退出 循环 : 





while (!responderClosed && dfsClient.clientRunning && !isLastPacketInBlock) 





当 运 行 期 间 发 生 异 常 ， 会 导致 responderClosed 设 置 为 true， 同 样 会 导致 循环 的 退出 : 





catch (Exception e) { 
if (!responderClosed) { 
lastException.set (e); 
errorState.setIinternalError (); 
errorState.markFirstNodeIfNotMarked (); 
synchronized (dataQueue) { 
dataQueue.notifyAll (); 
’ 
if (!errorState.isRestartingNode()) { 
LOG.warn ("Exception for " + block, e); 


} 
// 发 生 异 常会 使 得 responderClosed 设 置 为 true 
responderClosed = true; 








ResponseProcessor 内 部 执行 流程 见 图 9-6。 
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图 9-6 ”ResponseProcessor 内 部 执行 过 程 图 


9.3.4 ”DataStreamer 与 DFSOutputStream 的 关系 


在 上 文中 已 经 或 多 或 少 提 到 了 这 两 个 类 之 间 的 关系 ， 可 简要 概况 为 以 下 4 种 关系 : 
“ 创建 与 被 创建 的 关系 。 
“启动 与 被 启动 的 关系 。 
“ 关闭 与 被 关闭 的 关系 。 
“ 生产 者 与 消费 者 的 关系 。 
下 面 一 一 做 简要 的 分 析 。 


第 一 点 ， 创 建 与 被 创建 的 关系 ， 可 以 从 DFSOutputstream 的 构造 函数 中 看 出 : 





Private DFSOutputStream(DFSClient dfsClient, String src, 
EnumSet<CreateFlag> flags, Progressable progress, LocatedBlock lastBlock, 
HdfsFileStatus stat, DataChecksum checksum, String[] favoredNodes) 
throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


// 以 下 是 DataStreamer 的 构建 
if (!toNewBlock && lastBlock != null) { 
// 如 果 此 块 不 是 一 个 新 块 且 最 后 一 个 块 不 为 空 ， 则 append 操 作 是 追加 在 一 个 存在 的 块 上 
streamer = new DataStreamer (lastBlock, stat, dfsClient, src, progress, 
checksum, cachingSstrategy, byteArrayManager); 
getStreamer () .setBytesCurBlock (lastBlock.getBlockSize ()); 
adjustPacketChunkSize (stat); 
getStreamer () .setPipelineInConstruction (lastBlock); 
} else { 
computePacketChunkSize (dfsClient .getConf () .getWritePacketSize(), 
bytesPerChecksum); 
streamer = new DataStreamer (stat, 
lastBlock != null ? lastBlock.getBlock() : null, dfsClient, src, 
progress, checksum, cachingStrategy, byteArrayManager, favoredNodes); 





第 二 点 ， 启 动 与 被 启动 的 关系 ， 启 动 指 的 是 start 方 法 的 执行 。 





protected synchronized void start() { 
getStreamer () .start (); 
: 





getStreamer 方 法 用 于 获取 内 部 对 象 变量 dataStreamer: 





protected DataStreamer getStreamer() { 
return streamer; 


} 





三 点 ， 关 闭 与 被 关闭 的 关系 。 





Public void close () throws IOException { 

synchronized (this) { 

try (TraceScope ignored = dfsClient.newPathTraceScope( 
"DFSOutputStream#close", src)) { 
closeImpl (); 

} 

dfsClient .endFileLease (fileId); 
} 


protected synchronized void closeImpl() throws IOException { 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 
closeThreads (true); 
http://www.hzcourse.com/resource/readBook?path=/openresources/teach ebook/uncompressed/16100/0EBPS/Text/... 


} 
// 关闭 dataStreamer 以 及 responseProcessor 对 象 ，force 参 数 表 示 是 否 强制 关闭 
protected void closeThreads (boolean force) throws IOException { 
try { 
// Streamer 对 象 的 关闭 
getStreamer () .close (force); 
getStreamer () .join(); 
getStreamer () .closeSocket (); 
} catch (InterruptedException e) { 
throw new IOException ("Failed to shutdown streamer"); 
} finally { 
getStreamer () .setSocketToNu11 (); 
setClosed () 7 





在 这 里 会 关闭 streamer 相 关 的 类 。 








第 四 点 ， 生 产 者 与 消费 者 的 关系 。 这 个 关系 有 点 意思 ， 那 消费 对 象 是 什么 呢 ? 答案 是 DFSPacket， 也 就 是 dataQueue 中 所 存储 的 对 象 。 也 就 是 说 ，DFSOutputStream 中 的 方法 会 往 dataQueue 中 存 入 
DFSPacket， 然 后 DataStreamer 会 在 主 方法 中 获取 此 对 象 ， 也 就 是 上 文 分 析 的 场景 。 其 中 在 DFSOutputStream 中 写 入 数据 包 的 方法 如 下 : 











// Qsee FSOutputSummer#writeChunk () 
QOverride 
protected synchronized void writeChunk (byte[] b, int offset, int len, 
byte[] checksum, int ckoff, int cklen) throws IOException { 
dfsClient .checkOpen () 7 
CheckClosed (); 


if (len > bytesPerChecksum) { 
throw new IOException ("writeChunk() buffer size is " + len + 
"is larger than supported bytesPerChecksum " + 
bytesPerChecksum); 
} 
if (cklen != 0 && cklen != getChecksumSize()) { 
throw new IOException ("writeChunk() checksum size is supposed to be "+ 
getChecksumSize() + " but found to be " + cklen); 


} 
// 如 果 当 前 数据 包 为 空 ， 则 进行 构造 
if (currentPacket null) { 
currentPacket = createPacket (packetSize, chunksPerPacket, getStreamer () 
.getBytesCurBlock (), getStreamer() .getAndIincCurrentSeqno(), false); 
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} 

// 写 入 数据 到 当前 的 数据 包 中 

currentPacket .writeChecksum (checksum, ckoff, cklen); 

currentPacket .writeData (b, offset, len); 

currentPacket .incNumChunks (); 

getStreamer () .incBytesCurBlock (len); 

// 如 果 当 前 数据 包 已 经 写 满 ， 则 加 入 到 队列 中 等 待 传输 

if _ (currentPacket .getNumChunks () == CurrentPacket .getMaxChunks () || 

getStreamer () .getBytesCurBlock() == blockSize) { 

enqueueCurrentPacketFul1() 7 





人 

enqueueCurrentPacketFull 方 法 会 将 数据 包 写 入 dataQueue 中 : 

void enqueueCurrentPacket () throws IOException { 
getStreamer () .waitAndQueuePacket (currentPacket); 
CurrentPacket = null; 


} 





enqueueCurrentPacketFull 方 法 会 将 数据 包 写 入 dataQueue 中 : 





void enqueueCurrentPacket () throws IOException { 
getStreamer () .waitAndQueuePacket (currentPacket); 
CurrentPacket = null; 


} 











在 DFSOutputStream 的 close 方 法 中 ， 也 会 触发 一 次 最 后 清洗 数据 的 动作 ， 将 数据 写 出 到 各 个 DataNode 中 ， 也 会 调用 到 enqueueCurrentPacket 方 法 : 

















protected synchronized void closeImpl() throws IOException { 
// 将 缓存 中 的 数据 进行 写 出 
flushBuffer (); 
// 最 后 关闭 操作 的 时 候 ， 同 样 会 将 数据 包 加 入 到 队列 中 
if (currentPacket != null) { 
enqueueCurrentPacket (); 
} 


if (getStreamer () .getBytesCurBlock() != 0) { 
setCurrentPacketToEmpty (); 


} 

// 最 后 将 所 有 的 数据 刷 出 到 DataNode 中 

flushInternal (); 

// 在 streamer 对 象 关闭 前 获取 最 后 一 个 块 对 象 

// 在 前 面 的 操作 中 如 果 发 生 异 常 ， 此 块 对 象 将 会 为 nul1 

lastBlock = getStreamer () .getBlock () 7 
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DataStreamer 与 DFSOutputStream 之 间 的 关系 见 图 9-7。 











9.3.5 Streamer 线 程 泄漏 问题 








Streamer 线 程 泄漏 问题 是 笔者 在 学 习 DFSOutputStream 相 关 原 理 时 发 现 的 ， 过 程 算是 比较 意外 吧 。 线 程 泄漏 问题 可 以 类 比 于 内 存 泄 涡 ， 指 的 是 该 释放 的 空间 没 释放 。 线 程 泄漏 问题 同 理 ， 该 关闭 的 线 
程 对 象 没有 及 时 关闭 。 发 生 的 地 方 自然 而 然 是 在 DFSOutputStream 的 close 方 法 中 ， 这 里 重新 调 出 这 段 程序 : 








public void close() throws IOException { 
synchronized (this) { 
try (TraceScope ignored = dfsClient.newPathTraceScope( 
"DFSOutputStream#close", src)) { 
// 在 closeImp1 方 法 中 可 能 发 生 关 闭 异 常 
closeImpl (); 
} 
} 
dfsClient .endFileLease (fileId); 
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进入 closelmpI 实 质 的 关闭 方法 ， 仔 细 观 察 每 步 操作 可 能 存在 的 问题 。 


9-7 DataStreamer 与 DFSOutputStream 的 关系 

















protected synchronized void closeImpl () throws IOException { 
if (isClosed()) { 
getStreamer () .getLastException() .check (true); 
return; 


} 


try { 
// 将 缓冲 中 的 数据 写 出 
flushBuffer (); 


if (currentPacket != null) { 
enqueueCurrentPacket ()，; 
i 


if (getStreamer () .getBytesCurBlock() != 0) { 
setCurrentPacketToEmpty () 7 


} 

// 最 后 将 所 有 的 数据 刷 出 到 DataNode 中 

flushInternal (); 

// 在 streamer 对 象 关闭 前 获取 最 后 一 个 块 对 象 

// 在 前 面 的 操作 中 如 果 发 生 异 常 ， 此 块 对 象 将 会 为 nul1 

ExtendedBlock 、 lastBlock = getStreamer () .getBlock (); 
// 执行 线程 关闭 操作 


CloseThreads (true); 


try (TraceScope ignored = 
dfsClient .getTracer () .newScope ("completeFile")) { 
// 完成 文件 操作 
completeFile (lastBlock); 
} 
} catch (ClosedChannelException ignored) { 
finally { 
// 设置 已 关闭 状态 
setClosed () 7 








因为 可 能 存在 streamer 线 程 对 象 未 关闭 的 问题 ， 所 以 我 们 得 要 找到 在 closeThreads 方 法 之 前 可 能 有 问题 的 代码 。 如 果 你 比较 细心 的 话 ， 应 该 马上 发 现 问题 所 在 了 。 





flushBuffer (); 


if (currentPacket != null) { 
enqueueCurrentPacket (); 
} 


if (getStreamer () .getBytesCurBlock() != 0) { 
SetCurrentPacketToEmpty () 7 


} 
// 最 后 将 所 有 的 数据 刷 出 到 DataNode 中 
flushIinternal (); 




















从 flushBuffer 到 flushlnternal 中 的 操作 都 有 可 能 抛 出 IO 异常 ， 一 旦 抛 出 异常 程序 将 直接 跳 到 finally 代 码 处 进行 处 理 ， 中 间 的 closeThread 方 法 将 不 会 被 执行 到 ， 从 而 导致 DataStreamer 线 程 汇 
































bug 有 目前 已 经 提交 开源 社区 ， 并 且 已 有 相应 的 patch， 编 号 HDFS-9812。 解 决 办 法 很 简单 ， 在 这 
closeThread 方 法 直接 放 入 finally 代 码 处 进行 处 理 ， 详 细 信 息 可 以 查看 儿 RA 链 接 : 








https://issues.apache.org/jira/browse/HDFS-9812。 





层 代码 中 再 包 一 层 try-catch。 把 closeThread 方 法 放 入 新 增 try-catch 方 法 的 未 














尾 进行 处 理 ， 或 者 直接 














忆 
十 。 
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这 个 


这 








读 到 这 里 ， 如 果 你 仅仅 认为 只 有 此 处 可 能 会 有 潜在 问题 的 话 ， 那 就 错 了 。 在 笔者 后 续 对 此 代码 的 学 习 过 程 中 ， 发 现 对 于 closelmpI 方 法 ， 如 果 发 生 IO 异 常 ， 还 会 导致 DFSClient 端 无 法 正常 关闭 ， 相 关 代 
码 如 下 : 








public void close () throws IOException { 
synchronized (this) { 
try (TraceScope ignored = dfsClient.newPathTraceScope( 
"DFSOutputStream#close", src)) { 
// 如 果 closeImpl 发 生 IO 异 常 ，dfsClient .endFileLease 方 法 则 会 被 跳 过 
// 从 而 导致 文件 没有 完全 关闭 ， 造 成 内 存 泄露 
CloseImpl () 7 


} 
dfsClient .endFileLease (fileId); 
i 














文件 在 DFsClient 端 没有 正常 关闭 ， 会 导致 内 存 的 严重 浪费 ， 这 绝 不 是 一 个 小 问题 。 后 续 笔 者 同样 对 其 进行 修复 ， 并 提交 了 社区 JIRA 进 行 了 解决 ， 链 接 如 下 : 











https://issues.apache.org/jira/browse/HDFS-10549。 另 起 一 段 HDFS 作 为 一 套 比较 成 熟 的 分 布 式 系统 ， 为 什么 也 会 有 这 么 多 的 资源 泄露 问题 呢 ? 大 家 其 实 也 不 用 惊讶 ， 正 是 由 于 其 内 部 的 复杂 性 ， 所 
以 在 代码 上 出 现 一 些 大 大 小 小 的 问题 还 是 很 正常 的 ， 关 键 是 有 人 能 发 现 它 ， 解 决 它 。 














Replace Datanode on Failure 








HDFS 在 构建 Pipeline 进 行 写 数据 的 过 程 中 ， 如 果 Pipeline 中 的 某 个 DataNode 写 失败 了 ， 有 的 时 候 并 不 需要 完全 重新 构建 新 的 Pipeline。HDFS 可 以 支持 Replace Datanode on Failure 的 策略 。 也 就 是 








DataNode， 此 策略 将 不 会 生效 。 


9.4 小 结 


















































本 章 所 讲述 的 3 大 异常 场景 中 只 有 第 一 种 明显 感觉 到 ， 所 以 它 是 一 个 重点 的 内 容 ， 本 章 也 给 出 了 其 中 的 解决 方案 ， 大 家 可 以 将 其 运用 到 自身 的 系统 中 。 其 余 两 节 内 容 可 能 会 偏 于 理论 ， 稍 显 难民 ， 
建议 大 家 进行 源 代码 的 跟踪 调试 ， 进 一 步 了 解 其 运行 过 程 。 




















附录 ”如何 向 开源 社区 提交 自己 的 代码 








作为 一 名 职业 程序 员 ， 如 果 去 除 待遇 、 薪 资 等 等 的 因素 考虑 ， 从 纯 技术 的 角度 出 发 ， 如 何 才 能 达到 一 个 比较 高 的 境界 呢 ? 答案 是 与 最 顶尖 的 那 一 批 人 交流 合作 。 当 然 最 项 类 的 牛人 几乎 都 不 在 身边 ， 而 
且 大 多 在 国外 。 那 么 难道 就 没有 办 法 了 吗 ? 不 是 的 ， 不 要 忘 了 还 有 网 络 ! 可 以 通过 社区 、 邮 件 进行 交流 ， 提 出 自己 的 想法 。 这 些 人 往往 活跃 于 许多 开源 社区 ， 比 如 Apache 社 区 。 所 以 ， 如 果 一 个 普通 开发 者 
能 够 向 开源 社区 打 进 自己 的 补丁 (patch) ， 并 且 此 部 分 代码 能 够 被 合 入 主干 代码 中 ， 将 会 是 令 开发 者 非常 骄傲 的 一 件 事情 。 不 要 以 为 这 个 事情 很 难 ， 开 源 社区 的 代码 中 也 可 能 出 现 比如 显示 字符 出 错 这 样 
的 低级 错误 ， 如 果 被 你 发 现 了 ， 也 是 一 个 打 补 丁 的 机 会 。 总 之 一 句 话 ， 能 够 向 开源 社区 打 补 丁 的 人 ， 也 许 并 不 能 说 明 他 有 多 强 ， 但 是 一 定 程度 上 能 说 明 他 是 具有 钻研 精神 和 思考 能 力 的 。 毕竟 大 部 分 开发 人 
员 都 还 只 是 停留 在 使 用 这 些 开源 社区 产品 的 层面 上 ， 对 于 内 部 复杂 的 设计 与 实现 却 只 是 略 知 一 二 。 下 面 就 来 讨论 一 下 ， 作 为 一 个 非 Committer， 如 何 向 开源 社区 提交 代码 ， 打 进 自己 的 补丁 。 























































































































打 补 本 的 前 提 











首先 打 补丁 的 一 个 前 提 条 件 是 你 已 经 拥有 分 析 和 改造 已 有 开源 系统 代码 的 能 力 。 但 是 鉴于 开源 系统 本 身 的 复杂 性 ， 你 可 以 专注 于 研究 其 中 部 分 模块 代码 。 比 如 Hadoop 代 码 ， 你 可 以 选择 研究 HDFS， 或 
者 YARN， 亦 或 者 MapReduce 模 块 。 不 管 怎么 说 ， 你 要 拥有 阅读 和 改造 某 块 代码 的 能 力 。 


补丁 注意 事项 





补丁 是 如 何 打出 的 呢 ? 补丁 类 型 的 代码 在 某 种 程度 上 指 的 是 被 变动 过 的 代码 ， 包 括 修改 代码 和 增删 代码 ， 也 就 是 代码 的 变化 之 处 。 那 么 有 什么 工具 可 以 知道 代码 的 变化 呢 ? git diff 命 令 正 好 可 以 帮助 我 
们 解决 这 个 问题 。 通 过 git diff>your desFileName 命 令 就 可 以 导出 这 个 补丁 文件 了 ， 具 体 的 命令 使 用 方法 读者 可 以 自行 查阅 。 但 是 这 里 又 会 有 一 个 问题 ， 补 丁 打出 来 之 后 ， 只 能 说 明 这 段 补丁 代码 能 够 运行 
正常 ， 并 不 能 代表 这 个 补丁 遵守 了 一 定 的 规范 。 下 面 列 出 几 个 开源 社区 中 对 补丁 文件 的 规范 要 求 ， 从 图 A-1 中 的 Hadoop QA 测试 结果 表 中 ， 我 们 能 获知 一 些 规范 要 求 。 







































































Vote Subsystem Runtime Comment 

-1 pre-patch 19m 11s Findbugs (version ) appears to be broken on trunk. 

+1 @author Om 0s The patch does not contain any @author tags. 

+1 tests included 0m 0s The patch appears to include 1 new or modified test files. 
+1 javac 1im 13s There were no new javac warning messages. 


+1 javadoc 14m 53s There were no new javadoc warning messages. 


+1 release audit 0m 33s The applied patch does not increase the total number of release audit wamings. 


+1 checkstyle 1m 11s There were no new checkstyle issues. 
-1 whitespace Om 0s The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix. 
+1 install 2m 9s mvn install still works. 

eclipse:eclipse Om46s The patch built with eclipse:eclipse. 

findbugs 3m23s The patch appears to introduce 1 new Findbugs (version 3.0.0) warnings,. 

native 4m 19s Pre-build of native portion 

hdfs tests 58m 4s Tests failed in hadoop-hdfs. 

115m 46s 





图 A-1 Hadoop QA 测试 结果 


“ 补丁 必须 是 打 在 最 新 代码 之 上 的 ， 否 则 会 出 现 合并 代码 出 错 的 情况 。 因 为 补丁 中 会 有 每 行 代码 的 文件 名 和 对 应 位 置 ， 如 果 不 是 在 最 新 代码 上 的 修改 会 导致 出 错 的 情况 。 
: 每 行 代码 的 最 大 长 度 不 能 超过 80 个 字符 ， 和 否则 会 报 checkstyle 错 误 。 所 以 建议 的 方法 是 每 次 修改 完 自己 的 代码 后 ， 以 hadoop format 格 式 文件 的 方式 进行 格式 化 操作 。 

: 多余 空白 行 不 能 有 ， 和 否则 会 报 whitespace 警 告 。 多 余 空白 行 的 意思 指 的 是 回 车 另 起 一 行 的 时 候 ， 一 般 会 有 多 一 行 的 空白 行 ， 要 用 删除 键 把 此 行 前 面 的 空格 符 删 去 。 

“ 补丁 代码 需要 包含 对 应 的 测试 代码 ， 来 证 明 补丁 的 可 行 性 。 


“ 补丁 的 一 般 命 名 规范 是 : issue (问题 ) 序号 +.00 提 交 次 序 +.patch。 类 似 如 图 A-2 的 形式 。 
国 HDFS-9343.000.patch 2 days ago 
国 HDFS-9343.001.patch 2 days ago 


国 HDFS-9343.002.patch 2 days ago 
目 HDFS-9343.003.patch 2 days ago 








目 HDFS-9343.004.patch Yesterday 











A-2 补丁 命名 实例 





如 何 让 Committer 采 纳 你 的 补丁 





当 你 把 补丁 提交 到 开源 社区 的 时 候 ， 一 般 Committer 会 关注 到 你 的 issue， 可 能 会 迟 些 时 间 查 阅 你 的 补丁 。 如 果 他 认为 不 错 ， 会 给 你 提出 意见 ， 叫 你 修改 补丁 代码 ， 你 应 该 积极 响应 Committer 的 回复 ， 
及 时 进行 补丁 的 更 新 ， 这 会 让 人 家 对 你 产生 好 的 印象 。 如 果 出 现 了 类 似 于 图 A-3 中 +1 的 评语 ， 代 表 他 已 经 认同 你 的 补丁 代码 ， 基 本 上 可 以 被 合 入 主干 代码 了 。 


























v A Hitesh Shah added a comment - 2 days ago 


In any case, the patch looks fine. +1. 
Reply 














A-3 Patch 的 回复 认同 














这 就 是 代码 提交 的 整个 流程 了 ， 其 实 并 不 复杂 ， 但 是 周期 可 能 会 比较 长 。 因 为 有 的 时 候 需要 多 次 修改 代码 ， 这 需要 我 们 有 一 定 的 耐心 。 





总 结 





最 后 希望 国内 的 程序 员 能 够 向 开源 社区 多 做 贡献 ， 提 升 自身 的 影响 力 。 下 面 给 出 笔者 自己 早期 提交 的 2 个 issue 供 大 家 作为 参考 : 





* https://issues.apache.org/jira/browse/ HDFS-9303 


* https://issues.apache.org/jira/browse/MAPREDUCE-6499 


